Datenvisualisierung Rechnung

[#1]

Hallo, nachdem ich heute die Installation durchgeführt habe und die ersten Rechnungen geschrieben habe, fiel mir auf, dass wie bisher eine PDF-Variante in der DokVerw abgelegt wurde.

Öffne ich diese über einen PDF-Viewer erscheint diese, wie gewohnt.

Schaut man sich die Rechnung jedoch "übers Auge" an   , erscheint die Visualisierung der E-Rechnung, was ja grundsätzlich schon mal ganz in Ordnung ist.

Für den Kanzleibetrieb wäre es jedoch m.E. besser, das PDF-Anlage zur E-Rechnung auf der ersten Seite zu sehen und die Datenvisualisierung anschließend, da sich diese ja über mehrere Seiten zieht.

Ist das so gewollt und bleibt das so ? Ist jetzt nicht tragisch und man gewöhnt sich ja an Vieles, aber fürs schnelle Durchblättern wäre die PDF auf Blatt 1, meines Erachtens besser.

Vorsatz fürs neue Jahr: Resilienz ! (Können wir sicherlich alle reichlich brauchen 😉 )

[#2]

Ich hatte bisher nur sehr oberflächliche Tests mit E-Rechnungen und mit der Daten-Visualisierung gemacht.

Was mich aber bisher immer und sofort gestört hat, ist, dass bei der Visualisierung der Rechnungsdaten die Anzahl der Seiten 'explodiert'.

Frage:

"Ist das Kunst oder kann das weg ?"

oder anders gefragt: 

@Datev, darf man in diesem Punkt noch auf Optimierungen hoffen,
im Sinne von 'Datensparsamkeit' bzw. 'Seitensparsamkeit' ? 😎

Ich bin nämlich in diesem Punkt so gar nicht 'multipagingfähig' 😎

... ich frage mich sowieso, wer mit der Visualisierung von E-Rechnungen in der Praxis arbeiten will/soll/muss ...

[#3]

Liebe Datev,

da kann ich nicht mit arbeiten.

Kann ich das abschalten?

• Auf der ersten Seite einer Rechnung für z.B. eine ESt-Erklärung fehlt der Veranlagungszeitraum, man muss also scrollen, bei den Details steht er dann. Da die Datev bei der Rechnungsablage im DMD des Rechnungsjahr in das DMS-Feld Veranlagungsbezirk sendet, wird es also nochmals unübersichtlicher.  
•  Die letzte Seite muss an die erste Seite, den Rest braucht (nach Stand heute) kein Mensch(?).

Vielleicht können das die Kollegen testen:

Falls Sie die Datev-Rechnungen nativ im DMS ablegen, gucken Sie sich das "Pfd." doch jetzt mal an. 

• Aus z.B. bisher 156 Seiten wurden 484 Seiten
• 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 Datev-Gebühren-E-Rechnung bzw. deren Datenvisualisierung erscheint mir fehlerhalt, da anfangs offenbar keine Angaben vorhanden sind, für welchen Mandanten eine Position in Rechnung gestellt wird. Ich sehe nur eine endlose Liste von lt. Summenblatt 1228 Positionen, keine Info zum betroffenen Mandanten. 

Erst weiter hinten bei den vollständigen Rechnungsinformationen werden die Kosten mit Bezug zum Mandanten aufgeführt, sehr platzverschwendend und unübersichtlich, keine Mandantensummen.

Wenn das den gesetzlichen Vorgaben geschuldet ist, wäre das bitter, wenn es am Produktdesign liegen sollte, würde ich mich lieber erst nach Klärung dessen äußern.

Mfg. 

[#4]

Guten Morgen zusammen, 
in KaRe das gleiche Spiel bei der Anzeige der digitalen Belege. 
Man hat trotz aller Automatiken keine Zeit, bis zur letzten Seite zu scrollen. Die muss nach vorne. 
Ich hoffe, da tut sich noch was. 
Sicher bleiben wir nicht die Einzigen mit der Meinung. 🙂 

Startet alle gut!

[#5]

Im Rechnungswesen (Version 13.3) ist ein neuer Viewer verfügbar:

*Testbeleg

[#6]

@eliansawatzki 

Schön, dass die Testbelege so kurz sind. Im Echtbetrieb sieht das anders aus. Nehmen wir doch mal die DATEV Rechnung. Hier hat die Datenvisualisierung erheblich mehr Seiten als der pdf Teil der Rechnung. Trotz XML Datensatz findet sich eine wesentliche Infomation nicht im maschinenlesbaren Teil, nämlich die Bruttobeträge nach USt Satz. Da DATEV ja von Handarbeit geprägt ist, ist diese Information von grundlegender Bedeutung.

ReWe schafft es ja mit höchstwertiger KI nun die richtigen Werte wie Gesamtbetrag, Leistungserbringer, Rechnungsdatum, Leistungszeitraum und Rechnungsnummer aus dem XML Datensatz zu extrahieren. Die Brutto- und/oder Nettobeträge nach USt Satz schafft diese hochleistungs KI nicht.

Wäre ja nicht schlimm, DATEV kann ja eine Rechnung nach Nettobetrag aufteilen, schön und gut, wäre da nicht der Konstruktionsfehler dieser Funktion, am Ende bleibt für der letzten Betrag ein Rest, den jetzt mit der Funktion "Restbetrag in Buchung übernehmen" wäre ein großer Fehler - es handelt sich um den verbleibenden Bruttobetrag. Also am Ende doch wieder die Rechenmaschine anwerfen ...

Also trotz maschinenlesbarer Rechnung keine Arbeitserleichterung, eher Arbeitsbeschaffung.

Nun könnte argumentiert werden das DATEV ja einige Zusatzdienste anbietet, die das eventuell lösen könnten. Nur sind die mit Kosten belastet die bei einem recht hohen Preis für das Grundprodukt, zurückhaltend ausgedrückt, an Beutelschneiderei grenzen. Grundfunktionen sollte das Programm schon beherrschen.

[#7]

@einmalnoch 

---

Wäre ja nicht schlimm, DATEV kann ja eine Rechnung nach Nettobetrag aufteilen, schön und gut, wäre da nicht der Konstruktionsfehler dieser Funktion, am Ende bleibt für der letzten Betrag ein Rest, den jetzt mit der Funktion "Restbetrag in Buchung übernehmen" wäre ein großer Fehler - es handelt sich um den verbleibenden Bruttobetrag. Also am Ende doch wieder die Rechenmaschine anwerfen ..

---

Wenn Sie eine eine Netto-Aufteilung bearbeiten wird bei Verwendung der Funktion "Rest in Umsatz kopieren" für die letzte Buchung der Bruttowert angenommen. Dies erkennt man an der Veränderung der Bezeichnung in der Buchungszeile über dem Feld Umsatz (sie verändert sich von Nettoumsatz auf Bruttoumsatz). Das ist m. E. so auch richtig.

Ich erkenne kaum einen Mehrwert darin, manuell den Nettowert der letzten Buchung zu ermitteln, um diesen dann durch Erfassung eines Steuerschlüssels oder Verwendung eines Automatikkontos auf brutto hochrechnen zu lassen. Maximal bei äußerst komplexen Aufteilungen kann dies zur Kontrolle dienen.

[#8]

Nachvollziehbar und dennoch gehört die "gewohnte" Rechnungsansicht auf einer bzw. zwei Seiten dem XML-Visualisierung vorangestellt.

[#9]

Hätte man bei der Testrechnung die Rechtsform GmbH & Co. KG gewählt, wäre aufgefallen, dass

&

 von dem Viewer nicht in & umgewandelt wird. Zwar definiert der ZUGFeRD-Standard den Zeichensatz als UTF-8, aber nach meinem Verständnis sind HTML eigene Zeichen (", &, <, >, ' & ␉) auch in XML Dateien als Zeichen-Entität-Referenzen anzugeben. Daher würde ich behaupten, dass der Lieferant Matthies es in seiner XML richtig gemacht hat

und die Datenvisualisierung der Datev hier einen Fehler hat:

Belehrt mich bitte eines besseren wenn ich falsch liege. HTML ist nicht unbedingt mein Fachgebiet.

[#10]

@T_Ahmad 

Die XML Datei verwendet, wie auch HTML, den utf-8 Zeichensatz. Im Gegensatz zu HTML beschreibt XML aber keine Seite sondern beinhaltet nur utf-8 kodierte Zeichen. Alles was zwischen den spitzen Klammern steht wird angezeigt und verarbeitet, wie es da steht. Ergo hat der Viewer das richtig dargestellt, der Ersteller hat dort "&amp;" eingetragen.

Bei einer xml Datei handelt es sich um eine reine und damit "doofe" Textdatei. Bei einer HTML Datei muss ja der Parser auch noch den "Hübschkram" ermitteln und umsetzen, dafür braucht es dann die entsprechenden Codes die mit bestimmten Zeichen eingeleitet werden. Nun ist das kaufmännische "und" in HTML als Einleitungscode definiert und benötigt daher einen eigenen Code um als Zeichen in HTML dargestellt zu werden.

[#11]

... mit dieser 'Hyper-Intelligenz' hat die 'Künstliche Intelligenz' des Viewers natürlich nicht gerechnet 😎

Ich habe in den letzten Jahrzehnten (leider) auch nie versucht, die diversen Zeichensätze vollumfänglich zu verstehen 😣

[#12]

Moin,

---

@deusex schrieb: Für den Kanzleibetrieb wäre es jedoch m.E. besser, das PDF-Anlage zur E-Rechnung auf der ersten Seite zu sehen und die Datenvisualisierung anschließend, da sich diese ja über mehrere Seiten zieht.

---

 und

---

Ist das so gewollt und bleibt das so ? Ist jetzt nicht tragisch und man gewöhnt sich ja an Vieles, aber fürs schnelle Durchblättern wäre die PDF auf Blatt 1, meines Erachtens besser.

---

das fällt nun wohl unter "wie man es macht, macht man es nicht richtig...".

Da wird in den vergangenen Wochen teilweise vehemend darauf hingewiesen, dass bei einer Rechnungsprüfung/-buchung der XML-Datenbereich ausschlaggebend ist und der Sichtbereich PDF "nur" Beiwerk.... 

Und dann geht DATEV hin und baut eben den Viewer so, dass der XML-Bereich als erstes dargestellt wird... für Maschinen gebaut und nicht für Menschen... und nun isses auch wieder nicht genehm... 

Und damit wir uns richtig verstehen: Ich persönlich würde bei einer ZUGFeRD-Rechnung den Sichtbereich als primäre Ansicht auch favorisieren. Gerade beim Beispiel der DATEV-Rechnung, ist der Sichtbereich einfach schneller zu interpretieren.

DATEV wäre hier ggf. gut beraten einen "Schalter" einzubauen, bei dem der Anwender entscheiden kann, was er gern "vorn" stehen hätte. 

Bei einer X-Rechnung erübrigt sich das Thema... 

Beste Grüße und kommt gut ins neue Jahr
Christian Ockenfels

[#13]

@chrisocki 

Nur so ganz nebenbei:

Bei einer ZugFerD Rechnung muss der sichtbare pdf Teil in den verpflichtenden Angaben des UStG mit dem xml Teil der Rechnung übereinstimmen. Anderenfalls ist der Vorsteuerabzug gefährdet. Ein Viewer müsste diesen Prüfschritt eigentlich besser unterstützen.

[#14]

Hi, ich verstehe Sie absolut richtig. " Einige der schlimmsten Verbrechen, geschahen aus besten Absichten" oder auch "Man hat es doch nur gut gemeint" . . . heißt es ja landläufig.

Der "Maschine" ist es vollkommen schnurzpiepe, ob Sie den Datensatz auf Seite 1 oder auf Seite 30 liest; die "blättert und liest" in Zehntelsekunden, egal wo die Daten sind.

Eine Buchhalterin, die nun bei einem stattlichen Rechnungseingang/ Monat nun jedes Mal durchscrollen muss, um die wesentlichen Rechnungsbestandteile, ggf. für eine Aufteilung des Rechnungsbetrages auf verschiedene Kostenkonten oder gar Kostenstellen, zu erkennen, hat sicherlich eine Riesenfreude daran.

Ohne mich zu weit aus dem Fenster lehnen zu wollen, würde ich jetzt schon "wahrsagen", dass mit der Erstellung der Buchführungen Januar 2025 (jetzt ist ja erstmal noch Dezember 2024 dran) die Community bezüglich Kritik diesbezüglich aus den Kanzleien geflutet wird.

Da hilft es auch nicht auf den ASR/ASB zu verweisen, der diesbezüglich noch im Ferienpraktikanten-Status ist; wir haben alle Mandanten diesbezüglich umgestellt und ja, die Automatisierung "ist ganz gut", aber wird dieses Jahrzehnt noch keine Buchhalterin ersetzen.

Ich denke, der gewünschte Schalter, den Sie erwähnen, ist gar nicht nötig, denn welcher Mensch will zunächst einen visualisierten Datensatz zuerst sehen; das hat ja auch nichts dran "gewöhnen" zu tun, sondern ist schlichtweg ein unnötig aufwänder Prozess und der Maschine ists, wie erwähnt, wurscht.

Ich denke, ich spreche hier für 99% der "Buchhaltenden", dass das PDF vorne angestellt werden muss, damit das Belegbild beim buchen die erste Seite darstellt und nicht die erste von sechs Seiten einer Visualisierung.

[#15]

Guten Tag,

kann es sein, dass die datev selbst erkannt hat, dass es so nicht geht?

Bei mir wird heute gemeldet:

Mfg. 

[#16]

@einmalnoch Danke für die Erläuterung.

@chrisocki  schrieb:

Und damit wir uns richtig verstehen: Ich persönlich würde bei einer ZUGFeRD-Rechnung den Sichtbereich als primäre Ansicht auch favorisieren. Gerade beim Beispiel der DATEV-Rechnung, ist der Sichtbereich einfach schneller zu interpretieren.

Grundsätzlich finde ich die Sichtkomponente auch ästhetischer. Da der XML-Teil der Rechnung jedoch der ausschlaggebende ist, ist es eigentlich richtig sich auch nach diesem zu richten. Grundsätzlich ist es ja eine Arbeitserleichterung wenn die wichtigen Informationen einer Rechnung immer an der gleichen Stelle zu finden sind.

Da muss man aber einfach mal anmerken, dass der Viewer das nicht schön umsetzt. Sich durch fünf Seiten scrollen um irgendwo die Auflistung der einzelnen Seiten zur Aufteilung zu finden, ist irgendwie nicht so ganz das Wahre.

Der Platz auf den Seiten könnte viel sinnvoller genutzt werden und, Achtung ganz gewagter Gedanke, der Viewer würde mehr Sinn machen, wenn er die Daten im 16:9 Format, statt A4 hochkant visualisieren könnte. Ich bin gefühlt der einzige, der einen um 90° gedrehten Monitor zur Dokumentenansicht verwendet und ich glaube die meisten Leute haben das Belegfenster beim Buchen auf einem Monitor maximiert und verschwenden so wertvollen Platz der Informationen enthalten könnte.

@einmalnoch  schrieb:

Bei einer ZugFerD Rechnung muss der sichtbare pdf Teil in den verpflichtenden Angaben des UStG mit dem xml Teil der Rechnung übereinstimmen. Anderenfalls ist der Vorsteuerabzug gefährdet. Ein Viewer müsste diesen Prüfschritt eigentlich besser unterstützen.

So wie ich es verstanden hatte, ist bei Abweichungen der Inhalt der XML für den Vorsteuerabzug maßgeblich. Punkt 31 des BMF Schreibens vom 15.10.24 enthält folgenden Satz:

Im Fall von Abweichungen zwischen den strukturierten Rechnungsdaten und den sonstigen Informationen gehen die Daten des strukturierten Teils denen der Bilddatei vor.

Ein solcher Prüfschritt wäre natürlich super, müsste dann aber KI-gestützt (Oder Deep Learning für die ganz genauen) sein, was wiederum anfällig für Fehler sein kann.

Bei mir funktioniert der Viewer übrigens heute schon nicht mehr. Die gleiche Rechnung wie gestern, zeigt heute nur noch die Sichtkomponente an. KAREWE neu starten hilft auch nicht. Habe ich direkt an die Datev weitergegeben, da ich "glücklicherweise" heute eh einen Rückruf wegen eines anderen Programmfehlers bekam.

[#17]

Der Hinweis wurde mir vorhin nicht angezeigt und der Kollege von der Datev schien auch nichts davon zu wissen. Es scheint, als würde der Viewer die Ansicht in der Cloud generieren und nicht aus der XML lokal auf dem Rechner. Passt zur Cloud First Strategie der Datev, ist aber bei abnehmender Zuverlässigkeit der Cloud Infrastruktur (nicht nur in Nürnberg) nicht unbedingt nach meinem Geschmack. Kann man nix machen.

Ich wünsche mir zu 2025 von der Datev zumindest mal einen Monat in dem alles problemlos funktioniert, damit ich auch mal wieder Zeit fürs Tagesgeschäft habe. Aktuell scheinen Brände schneller auszubrechen als man sie löschen kann.

[#18]

---

@T_Ahmad  schrieb:

Ich wünsche mir zu 2025 von der Datev zumindest mal einen Monat in dem alles problemlos funktioniert...

Ich haben mir den Weltfrieden gewünscht. Beides scheint ähnlich wahrscheinlich . . . 😉

[#19]

Genau. 

Es ist einfach mal wieder typisch DATEV, uns da einfach die Visualisierung vor die Nase zu setzen. Vor allem habe ich bisher noch kein Schema erkennen können, wann das pdf der ZugFerD-Rechnung angezeigt wird und wann die Datenvisualisierung. Mag sein das es denen egal ist, die eh nicht mehr auf den Beleg schauen. Für mich kann ich das aber nicht behaupten. 

Wenn das der zukünftige Weg im REWE sein soll, ist auch jegliche Diskussion ob ZugFerD oder X-Rechnung hinfällig, wenn die DATEV für uns entscheidet, was wir sehen. 

Und leider wieder einmal ein Thread, wo garantiert DATEV-Mitarbeiter mitlesen, aber niemand sich traut mal etwas dazu zu schreiben.

So fängt doch das neue Jahr richtig gut an, vielen Dank @DATEV

Apropo, ein gesundes und erfolgreiches neues Jahr noch...

[#20]

Im Moment ist die Rechnung der BStbK für die Vollmachtsdatenbanknutzung 2024 eingetrudelt, die ich sogleich verbucht habe.

Auch hier sind die 3 Visualisierungsseiten vor der 1 PDF-Seite und damit ist das wohl kein DATEV-Ding, sondern wohl eher das allgemeine Vorgehen 🤔 (dislike)

Bleibt zu hoffen, dass hier noch ein wenig nachjustiert wird, denn das ist jetzt schon ein wenig befremdlich; insbesondere die Aussichten damit.

[#21]

Die Visualisierungsseiten werden doch erst durch die Datev aus der XML-Datei erzeugt? Oder reden wir an einander vorbei?

[#22]

Na klar, Sie haben ja völlig recht. Denkfehler. Danke für den "kleinen Kick".

[#23]

Gerade deswegen warte ich (und bestimmt viele andere auch) auf ein offizielles Statement der DATEV dazu.

Vielleicht kann sich da der Produktverantwortliche ja mal äußern, wie es zu dieser fürsorglichen Entscheidung kam. Vielleicht verstehe ich es einfach nicht, warum das jetzt besser ist als das pdf selber anschauen zu können... *IronieOff*

[#24]

@deusex 

Der facture-x Teil der Bundessteuerberaterkammerrechnung ist eine Katastrophe. Nicht nur, dass viele Zeichensatzfehler enthalten sind, es ist auch Nodefehler enthalten. Wenn dann noch die Tools behaupten der Datensatz sei nicht wohlgeformt darf mit Recht angenommen werden, dass die Rechnung nicht der Norm entspricht.

Das der Viewer von DATEV hier noch etwas lesbares produziert ist schon eine Leistung, die in spitzen Klammern dargestellten Texte sind ein Ausfluss der o. g. Fehler.

Merken wir uns: Da kommt noch Einiges auf uns zu.

[#25]

Hallo,

ich denke, die DATEV hat sich dazu entschieden, die Datenvisualisierung vor die Sichtkomponente (PDF) zu stellen, weil der Vorsteuerabzug ausschließlich aus dem strukturiertem Rechnungsteil möglich ist und dieser entsprechend primär genutzt werden sollte. (BMF-Schreiben vom 15.10.2024 zur E-Rechnungspflicht, Rz. 32)

[#26]

Mag sein, aber wenn Sie meinen obigen Beitrag gelesen haben, stellen Sie fest, dass dies für die Praxis kontraproduktiv ist; ich stelle RZ32 mal für alle zur Verfügung:

Enthält der Bildteil keine von dem strukturierten Teil abweichende Rechnungsangaben nach §§14, 14a UStG, handelt es sich bei dem Bildteil um ein inhaltlich identisches Mehrstück (vgl. auchAbschnitt 14c.1 Absatz 4 UStAE). Enthält der Bildteil dagegen abweichende Rechnungsangaben (z. B. aufgrund manipulativer Eingriffe eine andere Leistungsbeschreibung oder einen abweichenden Umsatzsteuerbetrag), stellt er ggf. eine weitere (sonstige) Rechnung dar, für die die Voraussetzungen des § 14c UStG zu prüfen sind. Dabei werden technisch begründete geringfügige Abweichungen, konkretisierende oder ergänzende Informationen (z. B. aus Gründen der Darstellung verkürzte Leistungsbeschreibung oder Rundungsdifferenzen) nicht beanstandet, wenn der Charakter als inhaltlich identisches Mehrstück nicht verloren geht. Ein Vorsteuerabzug ist auch in diesen Fällen nur aus dem strukturierten Rechnungsteil möglich.

Insofern kann die formelle Prüfung der Rechnung vom "Mehrstück" erfolgen, das in der Regel eine Seite, statt mindestens 3 der visualisierten XML hat.

Wer prüft die Rechnung auf formelle Richtigkeit ? 

Wer muss nun drei, vier oder fünf Seiten, statt einer Seite prüfen? . . . bei < 100 Eingangsrechnungen/Monat.

Was steht der Anzeige des "Mehrstückes" vor der Visualsierung entgegen? RZ 32 jedenfalls nicht. Das hatten Sie so auch nicht erwähnt (alles gut also), sondern vielmehr, dass die DATEV diese Reihenfolge "Original - Kopie" im Prinzip korrekt wählte . . . wenngleich der Praxisbezug (mal wieder) außen vor blieb.

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

[#27]

---

@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

Ein Vorsteuerabzug ist auch in diesen Fällen nur aus dem strukturierten Rechnungsteil möglich.

Daraus ergibt sich für mich, dass wir bei Eingangsrechnungen uns nach den Werten des XML-Datensatzes richten müssen. In 99,9 % der Fälle würde es keinen Unterschied machen, aber wenn es dann doch mal, aufgrund technischem oder menschlichem Versagen, zu Abweichungen kommt, ist das Geschrei groß.

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.

Wäre der Viewer zu Ende gedacht und würde die relevanten Werte immer an der selben Stelle und im besten Fall auf einer (Bildschirmgroßen) Seite darstellen, dann würde dieser gegenüber der Sichtkomponente sogar eine Arbeitserleichterung darstellen, da Rechnungslayouts bekanntermaßen alles andere als standardisiert sind.

[#28]

Habe jetzt im Kanzlei-Rewe auch erstmals eine visualisierte Rechnung angezeigt bekommen (eigene StB-Rechnung). Was ich nicht finde, ist der beigefügte Tätigkeitsnachweis.

Im Original pdf ist der als Anlage im Dokument beigefügt, dort sehe ich selbigen, beim Buchen in Kanzlei-Rewe finde ich weder auf den erste 3 Seiten (Visualisierung der Rechnung) noch auf der letzten Seite was.

Bei den Anlagen wird mir nur die Sichtkomponente angezeigt.

Wie komme ich beim Buchen an den Tätigkeitsnachweis?

[#29]

Guten Tag Finn,

das wäre dann typisch Datev. Der Programmierer / Entwickler setzt es so um, wie es sich die staatlichen Erfinder der E-Rechnung gedacht haben und denkt, er hätte seinen Job gut gemacht.

Leider hat er keine Kenntnisse von der Praxis und findet vermutlich zudem, dass sich die Nutzer bitte an die staatliche Vorgabe zu gewöhnen hätten. 

Was fehlt, ist die Fachaufsicht bei der Datev, die die Praxis kennt und dies korrigiert. Oder zumindest zulässt, dass sich das jeder nach eigenem Geschmack umstellen kann. 

Ich empfehle, einfach mal die Rechnung der Datev visualisiert anzusehen. Ein Traum  bei mir von 850 Seiten. 

Grüße stbab1

[#30]

Die Datev-Entwickler haben natürlich nicht damit gerechnet, dass man ausgerechnet die Datev-Rechnung als abschreckendes Beispiel zum Testen der Verwendbarkeit des Viewers bzw. der Visualisierung einer E-Rechnung verwenden könnte.

Sie sind vermutlich gewohnt, immer nur mit den Musterrechnungen aus den Musterpaketen zu arbeiten, die so schööön 'einfach gestrickt' sind 😎