Datenvisualisierung Rechnung

[#1]

Schön finde ich das auch nicht 😀

Ich finde auch, dass die Rechnung einfach in ihrem ursprünglichen Format angezeigt werden würde. Dafür gibt es extra das hybride ZUGFeRD-Format. 

Bei XRechnungen ist der Viewer sinnvoll, so ist er aber sehr verwirrend.

Auch der Export aus der DMS (bsp. wenn man die Rechnung per Mail versendet, oder exportiert, oder sogar ausdruckt) ist für mich vollkommen durcheinander. Mal wird die visualisierte Version ausgegeben, mal das Original. 

[#2]

---

@T_Ahmad  schrieb:

---

@deusex  schrieb:

Die Usability muss bei rechtlichen Umsetzungen IMMER im Vordergrund stehen. Würde ich konkret gefragt werden, würde ich antworten, dass sich darum niemand Gedanken gemacht hat . . .

---

Dem würde ich widersprechen. Im Vordergrund muss die rechtlich korrekte Vorgehensweise stehen und erst dann gilt es anhand dessen die bestmögliche Usability zu schaffen

Ich denke, das Offensichtliche muss nicht gesondert erwähnt werden.

Nochmals zur Klarstellung :

Wenn ich Alternativen habe, die rechtlich zutreffend sind, muss immer die Vorrang bekommen, welche die effizienteste Bearbeitung ermöglicht.

Ich hatte mit keinem Wort erwähnt, dass zu Gunsten der Usability, rechtliche Vorschriften zurückstehen sollten.

Manch einer könnte meinen ich versuche päpstlicher als der Papst zu sein. Ich finde jedoch, dass unser Berufsstand den Anspruch an sich selbst haben sollte, eine rechtlich einwandfreie Vorgehensweise bei der Leistungserbringung an den Tag zu legen. Auch wenn das in der Praxis häufig nicht der Fall ist.

---

Ihre Unterstellungen sind schon, nennen wir es mal sportlich, belasse ich aber mal dabei . . .  

---

[#3]

---

@deusex  schrieb:

Nochmals zur Klarstellung :

Wenn ich Alternativen habe, die rechtlich zutreffend sind, muss immer die Vorrang bekommen, welche die effizienteste Bearbeitung ermöglicht.

---

Das sehe ich genauso, ich glaube wir haben da etwas an einander vorbei geredet. Ich sehe, solange die Sichtkomponente nicht automatisch mit den XML-Daten abgeglichen wird, das Verbuchen anhand ersterer, als rechtlich zumindest risikobehaftet, da im Falle von Abweichungen, nicht der Datensatz verwendet wurde, welchem laut BMF Vorrang zu gewähren ist.

---

@deusex  schrieb:

Manch einer könnte meinen ich versuche päpstlicher als der Papst zu sein. Ich finde jedoch, dass unser Berufsstand den Anspruch an sich selbst haben sollte, eine rechtlich einwandfreie Vorgehensweise bei der Leistungserbringung an den Tag zu legen. Auch wenn das in der Praxis häufig nicht der Fall ist.

---

Ihre Unterstellungen sind schon, nennen wir es mal sportlich, belasse ich aber mal dabei . . .  

---

Damit wollte ich weder Ihnen noch jemand anderen persönlich etwas unterstellen. Wer jedoch den Blick in mehrere, gerade kleinere, Kanzleien hat, stellt oft fest, dass rechtliche Rahmenbedingungen im allgemeinen oft sehr locker gesehen werden, wenn keine externe Kontrolle erwartet wird. Das fängt bei den Grundregeln der Buchhaltung an. In der Ausbildung lernt man Dinge wie "keine Buchung ohne Beleg." In der Praxis herrscht oft eher die Haltung: "Soll der Prüfer es erst mal finden." oder mein Favorit: "Das sind die kleinen Fehler für den Prüfer, damit er ein Erfolgserlebnis hat und aufhört zu suchen."

Von unberechtigten Vorsteuerabzügen bei falschen OSS- und IOSS-Eingangsrechnungen will ich gar nicht anfangen.

Aber B2T: Wenn wir eine Visualisierung bekommen, die unseren Wünschen als Anwender entspricht, erübrigt sich diese Diskussion, da dann die Visualisierung übersichtlicher und schneller zu bearbeiten wäre, als die Originale Sichtkomponente.

[#4]

es gibt noch einen Bug:

die leistungsbegründende Anlage zur E-Rechnung ist im DMS ein zweites Dokument zur Rechnung, zudem noch in der Ansicht der strukturierten Daten enthalten, allerdings vor dem Rechnungsabbild ganz hinten. 

Ergebnis Ein unnötiges Dokument + ein unbenutzbar aufgebautes Dokument.

Frage an die Datev: warum wurde das so gestaltet? Ich verstehe es nicht. 

Mfg. 

Nachtrag: Ob der Rechnungsanhang vor oder nach dem Rechnungsbild auftaucht, scheint nicht einheitlich zu sein.

[#5]

Aber B2T: Wenn wir eine Visualisierung bekommen, die unseren Wünschen als Anwender entspricht, erübrigt sich diese Diskussion, da dann die Visualisierung übersichtlicher und schneller zu bearbeiten wäre, als die Originale Sichtkomponente.

Auch damit könnte ich sehr gut leben; besser sogar. Mir geht es grundsätzlich nicht um die B-Note, sondern um schnell auffindbare, vollständige Inhalte.

Nun wollte ich heute kurz in der Dokumentenverwaltung bei einem Mandanten über den Viewer die zuletzt abgerechnete FiBu-Rechnung an den Mandanten mit durchblättern suchen und habe festgestellt, dass die Daten zum Bearbeitungszeitraum erst auf der letzten Seite ganz klein unten aufgeführt sind; also scroll-Manöver.

Einfach so nicht gut. Nun, ich hoffe einfach mal, dass die Luft nach oben mit geraumer Zeit, geringer wird.

[#6]

Heute festgestellt:

Mandant stellt E-Rechnungen aus, lädt diese ins Unternehmen Online hoch.

Kanzlei Rewe erkennt die E-Rechnung, lädt auch den Viewer.

So weit so gut.

ABER:

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.

Das ist so unglaublich dämlich, dass es kaum möglich ist, in verständliche Worte zu fassen.

Mir scheint es als hätte die Datev eine Ausschreibung gemacht, wer den schlechtesten Viewer programmiert und dem Gewinner dann gesagt: "Jo, du hast den Job." Und wenn man dann sich noch die Zeit nimmt und die Genossen auf Programmfehler hinweist, wird man Ignoriert und bekommt als Antwort eine Werbe-Mail zugesandt.

Ehrlich jetzt, wo ist die versteckte Kamera? Das können die da drüben in Nürnberg doch nicht ernst meinen.

[#7]

Moin zusammen,

mir würde mal eine Aussage der Datev helfen: Also die xml-Datei wird mittels Viewer lesbar gemacht, dass wissen alle und verstehen alle.

Wie und auf welcher Grundlage erfolgt die Verbuchung in Kanzlei-Rewe. Wie kann die xml-Datei direkt verarbeitet werden? Ohne OCR, ohne Viewer, wie wird der Datensatz verarbeitet? Ich kann irgendwie nicht verstehen, dass das Viewer-Thema so groß ist, das ist doch nicht die Lösung der e-Rechnungen.

@Datev: Geht das oder geht das nicht? 

[#8]

---

@Norddeutsch_Gunns  schrieb:

mir würde mal eine Aussage der Datev helfen

---

Die Datev hält sich, aus gutem Grund, derzeit seht bedeckt dazu. Sonst müsste man ja eingestehen, dass man bei der Umsetzung ganz schönen Unsinn fabriziert hat.

---

@Norddeutsch_Gunns  schrieb:

Wie und auf welcher Grundlage erfolgt die Verbuchung in Kanzlei-Rewe. 

---

Derzeit (zumindest teilweise) noch anhand der OCR Werte aus der Sichtkomponente. Ob das ein Fehler im Programm ist oder man schlichtweg vergessen hat die Datenübernahme aus der XML zu programmieren, wird wohl niemand sagen können.

---

@Norddeutsch_Gunns  schrieb:

Wie und auf welcher Grundlage erfolgt die Verbuchung in Kanzlei-Rewe. Wie kann die xml-Datei direkt verarbeitet werden? Ohne OCR, ohne Viewer, wie wird der Datensatz verarbeitet? Ich kann irgendwie nicht verstehen, dass das Viewer-Thema so groß ist, das ist doch nicht die Lösung der e-Rechnungen.

@Datev: Geht das oder geht das nicht? 

---

Das geht. Und ist auch absolut notwendig. Wie lange man bei der Datev braucht um das einzusehen und umzusetzen, weiß niemand, da man vergebens auf ein Statement der Datev wartet.

[#9]

Es wäre einfach genial, wenn der ASR nicht erst in KaReWe, sondern bei E-Rechnungen bereits in DUO anspringen würde und in der Bearbeitungsform erweitert so schon einen fertigen Buchungssatz mit Personenkonto liefert, den ich nach KaReWe übertragen könnte.

Vielleicht kommt das ja noch. #believe

[#10]

Man sollte auch daran denken, dass diese Mehrseiten auch mehr Speicherkosten verursachen kann... Da freut dich die DATEV natürlich.

[#11]

Dei Bearbeitungsform "erweitert" geht doch gar nicht bei ASR oder habe ich mich da gedanklich verlaufen . . .

[#12]

---

@deusex  schrieb:

Dei Bearbeitungsform "erweitert" geht doch gar nicht bei ASR oder habe ich mich da gedanklich verlaufen . . .

---

Nein ist richtig, geht derzeit noch nicht.

[#13]

Hallo @deusex ,

Sie haben Sich keinesfalls verlaufen. Aber sehen Sie es mir nach, dass ich nur eine Wunschvorstellung geäußert bzw. laut geträumt habe.

Ich würde mich freuen, wenn der "Synergieeffekt", der sich aus einem vollständigen Datensatz der E-Rechnung in Zusammenhang mit den gigantischen Datensätzen der DATEV zu Rechnungen allgemein ergibt, irgendwann™ dazu nutzen ließe den ASR oder ein vergleichbares Produkt dazu zu bringen nahezu vollständig korrekte Buchungssätze zu übertragen. Den erweiterten Modus in DUO habe ich nur deshalb erwähnt, weil nur darüber Buchungssätze übertragen werden. 

Grüße 

[#14]

---

@lukasklein  schrieb:

Hallo @deusex ,

Sie haben Sich keinesfalls verlaufen. Aber sehen Sie es mir nach, dass ich nur eine Wunschvorstellung geäußert bzw. laut geträumt habe.

Ich würde mich freuen, wenn der "Synergieeffekt", der sich aus einem vollständigen Datensatz der E-Rechnung in Zusammenhang mit den gigantischen Datensätzen der DATEV zu Rechnungen allgemein ergibt, irgendwann™ dazu nutzen ließe den ASR oder ein vergleichbares Produkt dazu zu bringen nahezu vollständig korrekte Buchungssätze zu übertragen. Den erweiterten Modus in DUO habe ich nur deshalb erwähnt, weil nur darüber Buchungssätze übertragen werden. 

Grüße 

---

Genau das soll ja scheinbar vermieden werden. Ich komme aus der Zeit, als wir alle Mandanten "erweitert" hatten und sämtliche Rechnungen in DUO bereits dort bearbeitet, sprich kontiert haben, die Geschäftspartner angelegt etc.

Somit hatten wir stets die richtigen Buchungssätze in Rewe und konnten die "grün" durchlaufen lassen.

Mit Einführung des ASR wäre dies allerdings kontraproduktiv gewesen, weil (scheinbar) der ASR sonst überflüssig wäre und nichts "gelernt" hätte, weil der Lernprozess aus Rewe und in Rewe erfolgt und keine lernde Rückschreibung nach DUO möglich ist.

Die Rückschreibung nach DUO beinhaltet lediglich die Buchungsinformationen, nicht aber Infos für die KI (ich nenne es mal so, obwohl ich mit dem Begriff etwas auf Kriegsfuß stehe).

Insofern kann ich dies natürlich nachvollziehen, denn unser ASR soll ja lernen und nach ein paar Monate kann ich auch resümieren, dass diese Entscheidung kanzleiweit auf ASR umzustellen, lohnenswert war.

Ich möchte ungern Wünsche und Träume zerstören, denke aber gleichwohl, dass es dabei bleiben wird, wenngleich die Idee durchaus charmant ist.

Wir sind aber bei der DATEV schließlich nicht bei "Wünsch Dir was ! 😉

[#15]

---

@StBAB1  schrieb:

• Die Volltextsuche funktioniert nicht mehr richtig und findet das Klarschrift Pdf. nicht mehr. Bisher konnte man darüber mal eben bei einem Mandaten die laufenden Kosten prüfen, das geht jetzt nicht mehr. Das lesbare Pdf. ganz hinten wird von der Volltextsuche nicht mehr erreicht.
• Die Treffer haben rein gar nichts mit der Suchanfrage zu tun. Merkwürdig.

---

Die beiden Fehler könnten miteinander zusammen hängen, das müsstest du mal im Vergleich von (z.B.) Acrobat und DMS testen. Dass nämlich die Volltextsuche sehr wohl im PDF sucht und fündig wird, die entsprechende Seite des PDF zurück gibt, und der DMS-Viewer einfach dorthin springt ohne vorher die zusätzlichen Seiten aus der Visualisierung dazu zu addieren.

Als Beispiel mit konkreten Zahlen:

Zugferd mit 20 Seiten PDF, die XML-Visualisierung packt 250 Seiten dazu, insgesamt also 270 Seiten im DMS-Viewer. Volltextsuche sagt "Treffer auf Seite 13" (das schaut man im Acrobat nach) - der DMS-Viewer springt nun aber auf Seite 13 statt 250+13=263.

[#16]

Was mir gerade bei der Verbuchung der DATEV Rechnung aufgefallen ist: Relevant ist ja der *.xml Anteil. Okay.

Aber muss die Visualisierung SO aussehen? Was soll der ganze Whitespace? Das bläht den visuellen Teil um Faktor 3 (oder so auf)? Wozu?

Und: Erst mal ein paar dutzend Seiten scrollen um die Gesamtsummen zu sehen ist auch sinnbefreit. Warum nicht den anderen Eckdaten auf Seite 1? Ich will effizient Arbeiten können und nicht willenlos die page up / page down Tasten verschleißen (oder das Scrollrad durchdrehen lassen).

Was mich wieder zu der Frage führt: Fragen die Programmierer / UX Designer der DATEV auch mal Leute die den Quatsch benutzen müssen?

[#17]

---

@jafrasch  schrieb:

Fragen die Programmierer / UX Designer der DATEV auch mal Leute die den Quatsch benutzen müssen?

---

Dafür gibt es ja Pilotierung (deren Rückmeldung man dann ignoriert) und das Forum. DATEV selbst arbeitet schließlich mit SAP. 😉

[#18]

Dafür bräuchte es ja noch nicht einmal eine umständliche Pilotierung. Blitzumfrage auf wasweisich Tiktok (auf Mastodon sind die ja nicht) würde da schon reichen...

[#19]

@lukasklein 

Welches DATEV Produkt sollte denn in der Lage sein einen Nutzen auf Mandantenebene aus der E-Rechnung zu ziehen?

Ich sehe Keines.

Wer kann eine Rechnung sachlich prüfen?

Richtig, der Mandant. Ich habe keine Ahnung was der Mandant bestellt hat. Oder Sie? Oder DATEV?

Die ganze E-Rechnung ergibt doch nur Sinn, wenn die E-Rechnung einen komplett digitalen Ablauf abschließt und das kann nur auf Mandantenebene stattfinden.

Ich kann mich auf DATEV Ebene glücklich schätzen wenn UO einen Kreditoren trifft und Datum sowie Debitor oder Kreditor trifft. Das hat sich auch nicht mit der E-Rechnung auch nicht verbessert, UO schlägt mir bei der Bundessteuerberaterkammer doch tatsächlich vor einen neuen Kreditor anzulegen weil "KdöR fehlt. Also bleibt das Gespann UO/ReWe immer auf Handarbeit angewiesen.

Welchen Nutzen hätte denn ein weiteres Vorsystem wie z. B. der automatische Rechnungsdatenservice?

Eigentlich wenig. Auch dieser muss sich Informationen aus den Daten beschaffen, nur dumm, dass dieser Dienst keine Daten aus dem Bestellvorgang bekommt.

Was bringt die Kombination Mandant - UO?

Auch nur Handarbeit, der Mandant hat wenig Nutzen durch die xml Daten da diese mangels Bestellsystem abgeglichen werden können.

Daraus ist abzuleiten, dass die E-Rechnung in Unternehmen, die keine intern Bestellsysteme zu bezahlbaren Preisen haben, einen geringen Nutzfaktor hat.

Und jetzt kommen wir als Berater. Wir müssen die fachliche Prüfung durchführen, also die richtige Anwendung des UStG. Haben wir dabei technische Unterstützung? Die fachliche Erkennung von Rechnungen in ReWe ist so intelligent wie ... (kann sich jeder aussuchen).

Ergo sind wir auf eine vernünftige Sichtkomponente angewiesen! Diese muss die notwendigen Daten in einer Art Synapse knackig darstellen und nicht notwendige Daten schlicht ausblenden. In Verbindung mit einer guten Matchingkomponente lassen sich Änderungen (wenn notwendig, also die eigene Fibu) auch direkt in die ReWe Stammdaten übernehmen (Wunschtraum).

Also, wo finde ich den Vorteil der E-Rechnung im DATEV Kosmos?

Ich finde keine Komponente mit der ich die DATEV Rechnung automatisch sinnvoll zerlegen kann, also kein KOST, keine Übergabe in EO. Dafür muss ich auf andere Hilfskrücken aus der Steinzeit zurückgreifen. Aber um die Aufteilung des Rechnungsbetrages nach USt-Sätzen hinzubekommen darf ich nun x Seiten durchsuchen um diese Werte im pdf Sichtteil der Rechnung zu finden.

[#20]

---

@deusex  schrieb:

Mit Einführung des ASR wäre dies allerdings kontraproduktiv gewesen, weil (scheinbar) der ASR sonst überflüssig wäre und nichts "gelernt" hätte, weil der Lernprozess aus Rewe und in Rewe erfolgt und keine lernde Rückschreibung nach DUO möglich ist.

Die Rückschreibung nach DUO beinhaltet lediglich die Buchungsinformationen, nicht aber Infos für die KI (ich nenne es mal so, obwohl ich mit dem Begriff etwas auf Kriegsfuß stehe).

---

Nach meinem Verständnis erfolgt der Lernprozess im Rechenzentrum, daher ist es auch notwendig die Buchungsstapel zu übermitteln. Damit daraus dann Machine Learning (ist zutreffender als KI) erfolgen kann, wäre es logischerweise auch notwendig, dass die Buchungsinformationen ins Unternehmen Online (und damit ins Rechenzentrum) übertragen werden. Wenn die Erzeugung von Vorschlägen rein auf dem Buchungssatz aus dem übertragenen Stapel und dem darin enthaltenen Beleglink basiert, können wir nicht erwarten, dass wir in Naher Zukunft eine Unterstützung für den erweiterten Modus bekommen. 

Irgendwie scheint mir der ASR nicht ganz zu ende gedacht.

[#21]

Ich bin sehr froh, denn vorkontierten "Stuss" meiner Mandanten nicht mehr überwachen zu müssen; da ist mir das gelbe ? in Rewe deutlich sympathischer.

Insofern sehe ich keinerlei Bewandtnis, warum überhaupt der erweiterte Modus jetzt oder gar in Zukunft überhaupt noch weiter bekümmert werden muss; dies steht doch dem Prinzip des ASR entgegen.

Ich spreche da ausschließlich für mich und die Arbeitsabläufe bei unseren FiBu-Mandanten.

Die Rückmeldungen für diese Änderung war durchweg positiv, auch weil die übrigen Funktionen wie gewohnt bestehen bleiben und den Mandanten wiederum ein wenig Arbeit abgenommen werden kann; das ist doch der Sinn des ASR.

Man könnte auch den Gedanken fassen, dass gerade mit Wegfall des erweiterten Modus, der ASR bis zum Ende gedacht wurde . . .

[#22]

Die Datev hat sich jetzt wohl zu der Datenvisualisierung in Dokument 1038182 geäußert.
Die elektronischen Daten haben in jeder Hinsicht Vorrang gegenüber der PDF-Datei. 
Das wird zukünftig wohl ein riesiger Kontrollaufwand werden😖
Wenn Theorie und Praxis aufeinander treffen...

[#23]

---

@KruegerKOB  schrieb:

Die Datev hat sich jetzt wohl zu der Datenvisualisierung in Dokument 1038182 geäußert.
Die elektronischen Daten haben in jeder Hinsicht Vorrang gegenüber der PDF-Datei. 
Das wird zukünftig wohl ein riesiger Kontrollaufwand werden😖
Wenn Theorie und Praxis aufeinander treffen...

---

Nur gut, dass sich die Datev nun auch mal dazu äußert, wenn auch indirekt. Antworten auf unsere Anmerkungen, oder besser noch umsetzen unserer Verbesserungsvorschläge wäre natürlich besser gewesen, aber ist wohl zu viel verlangt.

Die letzten beiden Sätze des besagten Dokuments

Die Datenvisualisierung bietet eine bestmögliche Unterstützung, um eine vollumfängliche Ansicht der strukturierten Daten zu erhalten. Damit werden die gesetzlichen Vorgaben zur E-Rechnung in den DATEV-Programmen erfüllt.

Ist das noch Marketing-Neusprech oder schon Mobbing der Anwender?

Ich versuche mich mit dem Bashing zurück zu halten, aber man macht es mir wirklich nicht leicht. Als selbstbuchender Unternehmer werde ich mich nach Abschluss von 2024 wohl um Alternativen bemühen müssen. Als Arbeitnehmer in der Kanzlei bin ich weiterhin der Datev ausgeliefert. 

[#24]

Schönen guten Abend,

ich habe gerade meine eigene letzte DATEV-Rechnung gebucht. Der digitale Beleg ist 18 (!) Seiten lang. 13 Seiten Visualisierung und 5 Seiten pdf-Element.

Ich bin da einigermaßen sprachlos, wollte dies dennoch gerne in der Communitiy teilen. Also ganz ehrlich, wie viel Zeit soll man da für die Prüfung der VoSt-Abzugsvoraussetzungen verbraten. Ehrlich, das macht mich richtig fassungslos. Naja vielleicht kann uns das Phillip Lahm ja noch gut verkaufen.

Schönen Abend noch.

MfG

A. Boese

[#25]

Guten Tag,

zunächst möchten wir uns herzlich für Ihre Anmerkungen und konstruktive Kritik bedanken. Wir schätzen jeden Ihrer Beiträge und nehmen Ihre Rückmeldungen sehr ernst.

Wir verstehen Ihre Anliegen. Da der XML-Datensatz in jeder E-Rechnung, unabhängig vom Format, führend ist, stellen wir die Datenvisualisierung in den Vordergrund, um eine korrekte Bearbeitung der Rechnung zu unterstützen. Die Sichtkomponente wird als Anhang in der Datenvisualisierung bereitgestellt und ist im DMS-Viewer mit einem Mausklick zugänglich. Es besteht also kein Bedarf, die Rechnung durchzuscrollen, auch um auf die weiteren Anhänge zuzugreifen.

Wir sind uns bewusst, dass die generierte Datenvisualisierung derzeit größer ausfällt als die ursprüngliche Sichtkomponente, da die strukturierten Daten in der Regel mehr Informationen beinhalten und nur der Anwender beurteilen kann, welche Informationen er benötigt.

Besonders möchten wir auf die Zweiteilung der Datenvisualisierung hinweisen:

• Übersicht: Alle steuerrelevanten Informationen sind in einer kompakten Rechnungsübersicht am Anfang dargestellt. Unser Ziel war es, diese Übersicht auf möglichst wenige Seiten zu begrenzen, um den Buchungsprozess zu erleichtern.
• Details: Im zweiten Teil der Datenvisualisierung finden Sie die Detailinformationen, sodass alle Informationen des strukturierten Datensatzes angezeigt werden und Sie sich ein vollständiges Bild über den Rechnungsinhalt machen können.

Falls Sie der Meinung sind, dass zusätzliche Informationen in die Übersicht auf der ersten Seite aufgenommen werden sollten, lassen Sie es uns bitte wissen. Wir prüfen jede Anforderung sorgfältig und setzen notwendige Änderungen bei positiver Bewertung zeitnah um.

Weitere Informationen zur Datenvisualisierung finden Sie in unserem Info-DB-Dokument „Datenvisualisierung von E-Rechnungen“ im DATEV Hilfe-Center. Dieses Dokument wird regelmäßig aktualisiert.

Vielen Dank für Ihr Verständnis und Ihre Unterstützung.

Slawomir Procelewski

PO Zentrale E-Rechnung Dienste

[#26]

Guten Tag @Slawomir_Procelewski ,

da Sie schreiben die Rückmeldungen sehr ernst zu nehmen:

Können wir Anwender damit rechnen, dass die Anforderungen, welche in diversen Beiträgen ausführlich beschrieben wurden,  durch die DATEV umgesetzt werden? Oder wird eine Verbesserung der Visualisierung mit der Begründung, dass sich die On Premise Anwendungen im Wartungsmodus befinden kategorisch abgelehnt?

Sehen Sie mir die direkte und unverblümte Nachfrage nach. Derzeit wirken die Äußerungen der DATEV, zu der Kritik der Anwender hinsichtlich der E-Rechnungsvisualisierung, auf mich sehr ausweichend. Eine klare Kommunikation hinsichtlich der (ggf. nicht) geplanten Änderungen würde dem Vertrauen in die Genossenschaft durchaus zuträglich sein.

Sollte eine Überarbeitung der Visualisierung realistisch erscheinen, bin ich gerne bereit die bislang geäußerten Verbesserungswünsche zusammenzutragen und hinsichtlich der Anforderungen der Anwender zur Seite zu stehen.

Ich freue mich auf eine Antwort von Ihnen.

LG TA

[#27]

Sehr geehrter Herr Procelewski,

Ihre Begründungen und Überlegungen in Ehren, es hilft aber nicht, das Arbeitsergebnis ist und bleibt untauglich.

Niemandem ist geholfen, wenn Sie etwas verteidigen, dass Sie so dauerhaft nicht halten werden können. Mich erinnert dies stark an die Diskussionen um den Datev-Mandantenübertrag online, auch dort wurde etwas untaugliches entwickelt, datevseitig hartnäckig verteidigt, bis man sich dem Kundenwillen doch (halbwegs) gebeugt hat. 

Das Arbeitsergebnis Ihrer Entwicklung ist und bleibt ungeeignet für den Alltag.

Das was ich im DMS bei meinen eigenen Rechnungen sehe, ist nicht effizient nutzbar, da helfen auch Ihre Begründungen nicht. 

Die zuerst sichtbaren steuerrelevanten Informationen sind nicht nutzbar. Bitte sehen Sie sich Ihr Arbeitsergebnis doch einmal bei einer einfachen Rechnung über normaler Weise einer DINA4-Seite an:

Es fehlt die Angabe des Veranlagungszeitraumes. Es erfolgt eine penetrante ständig wiederholende Angabe der STBVV. Diese Visualisierung ist also nicht nutzbar und damit sinnlos.

Detailvisualisierung:

Eine Aufbereitung in maximal denkbarer Platzverschwendung und außergewöhnlich schlechter Lesbarkeit. Die Frage nach dem Veranlagungszeitraum wird in Schriftgröße 2 dargestellt. 

Durch die wahllose Verteilung von Informationen auf einer großen Fläche ist diese Auswertung nur schwerlich nutzbar.

Ihr Entwicklungsergebnis ist leider nicht nutzbar und sollte grundsätzlich überarbeitet werden. 

1. freie Auswahl der angezeigten Komponenten in frei auswählbarer Reihenfolge
2. Überarbeitung des Layouts in den Visulisierungsvarianten auf einzeilig
3. Stete Angabe der abgerechneten Veranlagungszeiträume 
4. Zusammenfassung der Visualisierungsvarianten 1 + 2
5. Ablage der Rechnungen im DMS in sinnvoller Weise:

• Zulassen einer automatisierten Ablage mit Eingriffsmöglichkeit, z.B. Knigge
• Vorbelegung des Veranlagungszeitraums im DMS mit "Veranlagungszeitraum, nicht mit dem (an dieser Stelle unsinnigen Rechnungsjahr)
• Bearbeitung der Beschreibung im DMS: Der Text ist unsinnig lang ohne Abkürzungen, also z.B.  Rechnung 250139/2025 vom 26.01.2025, Aufträge 22/23, Mandant 16189. In der Handakte interessiertdoch nur, dass die Steuererklärung 2025 abgerechnet habe, das Datum steht im Datumsfeld, der veranlagungszeitraum unter Veranlagungszeitraum. 

 Mfg. 

stbab1

[#28]

Falls Sie der Meinung sind, dass zusätzliche Informationen in die Übersicht auf der ersten Seite aufgenommen werden sollten, lassen Sie es uns bitte wissen. Wir prüfen jede Anforderung sorgfältig und setzen notwendige Änderungen bei positiver Bewertung zeitnah um.

@Slawomir_Procelewski :

Ich schließe mich konkret meinem Vorredner an.

Es ist über die Vorschau in der Dokumentverwaltung regelmäßig notwendig die Rechnung zu sichten, welche Rechnung zuletzt für welchen FiBu- oder LoBu-Zeitraum geschrieben wurde.

Um diese Info zu erhalten, reicht es nun nicht mehr,die Rechnungsdateien " über den Viewer durchzublättern, sondern muss jede einzelne Vorschau auf die vorletzte Seite runterscrollen, um die Information zu erhalten.

Der Bearbeitungszeitraum (auch Veranlagungszeitraum) sind essentielle Informationen einer Rechnung und nicht nur Nebeninformationen.

Dies könnten Sie beurteilen, wenn sie den Blickwinkel des Nutzers einnehmen könnten.

Insbesondere auch bereits die erwähnte Schriftgröße ist für mich trotz Lesebrille (1,5d) eine echte Herausforderung und dabei gibt es noch so viel nutzloses "Weiß" in der Visualisierung.

Wer ist auf die Idee gekommen, die Positionen zu zweiteilen; das belegt doch mehr Platz, als es bringt. Also wirklich Gedanken hat sich hier nicht wirklich jemand gemacht, um das unverblümt zu sagen.

Es ist genügend Platz und wenn es technisch nicht anders möglich ist (was ich nicht glaube), positionieren Sie eben Positionen (2) direkt hinter Positionen (1), denn alles was danach kommt ist unwichtiger !

Es sieht grade so aus, als dass man den Fehler kurz vor Release bemerkt und einen zweiten Teil der Gebührenposition einfach noch hastig und lieblos hinten angepappt hat; mit Usability hat das nichts zu tun und kommt indes auch recht amateurhaft an. Offenbar ist DATEV an einer Reputation nicht viel gelegen, schaut man sich die grundsätzlichen Entwicklungen in den Cloud-Anwendungen an.

Ich stelle die Frage heute zum 20ten-Mal. Hat sich bei dem "Design" wirklich jemand um eine Usability gekümmert oder geht es nur darum, schöne, bunte, big-button-Seiten zu designen ? Dran denken: Form follows function. Immer.

[#29]

Guten Tag @StBAB1 und @T_Ahmad,

vielen Dank für eure wertvollen Anmerkungen. Ich werde eure Anregungen zur Visualisierung so gut wie möglich beantworten, muss jedoch darauf hinweisen, dass ich zu den DMS-spezifischen Anforderungen wenig beitragen kann.

1. Unterscheidung onPremise/online: Die Visualisierung der E-Rechnung erfolgt in einer Online-Komponente. Daher sind alle zukünftigen Anpassungen unmittelbar nach der Freischaltung für alle Anwendungen sichtbar, die die neue Visualisierung umsetzen – unabhängig davon, ob sie onPremise oder online sind.

2. Fehlender Veranlagungszeitraum in der Übersicht: Dieses Problem ist uns bekannt und befindet sich bereits in der Umsetzung.

3. Zu viel Platz zwischen Einträgen: Auch dieses Problem wird momentan analysiert und zeitnah behoben, sowohl in der Übersicht als auch in den Details.

4. Überarbeitung des Layouts in den Visualisierungsvarianten auf einzeilig: Dieses Thema wird in Verbindung mit dem vorherigen Punkt angegangen.

5. Freie Auswahl der angezeigten Komponenten: Ich verstehe dies als Wunsch, das Übersichtsteil frei gestaltbar zu machen. Aufgrund der Vielzahl verschiedener Anwendungen, die die Visualisierung nutzen oder nutzen werden, halte ich dies für schwierig umsetzbar. Zudem streben wir an, dass sowohl Rechnungssender als auch Rechnungsempfänger dieselbe Visualisierung verwenden, um den Abgleich zu erleichtern.

Ich hoffe, diese Informationen sind hilfreich.

Beste Grüße,

Slawomir Procelewski

PO Zentrale E-Rechnung Dienste

[#30]

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.

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.

Mit freundlichen Grüßen,

Slawomir Procelewski

PO Zentrale E-Rechnung Dienste