Ich verbuche die ersten E-Rechnungen über Unternehmen-Online und bin vollkommen genervt: erst kommen seitenweise die Angaben aus der Zugpferddatei oder wie immer der Krempel auch heissen mag, dann erst die Ansicht der eigentlichen Rechnung zum Verbuchen. Sprich, jeder Rechnung muss erstmal wieder bis zum Ende durchgescrollt werden.... diese ist nervig und kostet Zeit.
Kann man, wenn ja wie und wo, die Ansicht so einstellen, dass erst die Rechnung kommt und danach der Anhang?
Das wurde bereits hier irgendwo Diskutiert. Hat wohl damit was zu tun, dass der XML Anhang mit seinen Angaben vorragen vor der Bilddatei hat.
Grüße
AKW
Naja, eigentlich ist der XML-Teil des Beleges ja die eigentliche Rechnung. Daher hat die Datev das an erster Stelle. Das nun für Vorsteuerzwecke das Abbild langen soll kam erst im Dezember.
@Gelöschter Nutzer schrieb:dann erst die Ansicht der eigentlichen Rechnung zum Verbuchen.
Nein, das ist nicht die eigentliche Rechnung. Danach sollten Sie auf keinen Fall buchen!
Die Sichtkomponente der Zugferd-Datei ist nur ein Hilfsmittel.
Wie @OliverFrank schon beschrieb, ist "der Krempel" die originäre, relevante Rechnung.
Danke für die Info....... nur blöde, dass diese E-Rg. erstmal alle gleich aussehen. Es ist mega anstrengend, bis man findet, wer der Absender ist (kein Logo ö.ä. wo man sonst sofort gesehen hat, wer der Absender ist), alles die gleiche Schriftgröße.... nicht ist irgendwo ersichtlich, wo man bisher sofort gesehen hat, um welche Rechnung es sich handelt.......
Dafür steht die Angabe im Datensatz und wird automatisch in Ihre Buchungszeile übernommen. Also da finde ich die automatische Übernahme n Tick besser 😉
@Gelöschter Nutzer schrieb:Danke für die Info....... nur blöde, dass diese E-Rg. erstmal alle gleich aussehen. Es ist mega anstrengend, bis man findet, wer der Absender ist (kein Logo ö.ä. wo man sonst sofort gesehen hat, wer der Absender ist), alles die gleiche Schriftgröße.... nicht ist irgendwo ersichtlich, wo man bisher sofort gesehen hat, um welche Rechnung es sich handelt.......
Stimmt.
Also ein Träumchen wäre ja ein Viewer, der beide Rechnungsbestandteile nebeneinander darstellt, links die XML, rechts die Sichtkomponente und man dann abschnittsweise die XML durchscrollen kann und dabei der Viewer parallel die Sichtkomponente analysiert und genau den entsprechenden Rechnungsteil in der Sichtkomponente hervorhebt.
Das würde einen Vergleich ermöglichen, Betrugsversuche erkennen lassen, Fehler verdeutlichen... was auch immer.
Da könnte man doch sicher KI zielführend einsetzen, wenn die es einem schon ermöglicht, Gerichtsurteile in Gedichtform zusammenzufassen.
? bei mir wird leider nichts übernommen..... nur das übliche (Betrag, Rg.-Nummer etc.) und das teilweise auch falsch.
Das Programm erkennt überwiegend nicht mal Rg.-Datum und/oder Leistungsdatum - aber das nur nebenher.
Für mich ist es mal wieder eine Neuerung, die mir mehr Arbeit und Ärger beschert.
@Gelöschter Nutzer schrieb:? bei mir wird leider nichts übernommen..... nur das übliche (Betrag, Rg.-Nummer etc.) und das teilweise auch falsch.
Verstehe ich das richtig? Sie importieren eine ZUGFeRD-Rechnung in Unternehmen Online und der Betrag wird falsch übernommen?
Da würde ich empfehlen, mal direkt einen Servicekontakt bei der DATEV aufzumachen. Das sollte sich die Technik mal anschauen.
Das finde ich bedenklich.
will nicht weiter rumnerven und meckern - meine Frage zu den E-Rg. ist ja vom Grundsatz her erstmal beantwortet (wenn ich auch unbefriedigend) und ich weiß, daß die Anzeige so erstmal in Ordnung ist und wohl auch nicht zu ändern......
aber abschließend zu den fehlerhaften Daten beim Einlesen über UnternehmenOnline:
in der Tat erkennt das Programm (selten) den Betrag nicht oder falsch, des öfteren werden Rg.-Nummer nicht erkannt (bzw. wird die Tel.-NR. als Rg.-Nr. vorgeschlagen), sehr oft werden die Daten Leistungs- und Rechnungsdatum vertauscht oder gar nicht erkannt.,.....
Auskunft DATEV (wie immer): "kann nicht sein" "gibt es nicht" "kann ich Ihnen auch nicht erklären".....
also wurschtelt man weiter so vor sich hin und braucht mehr Zeit wie früher, als man die Belege manuell erfasst hat.
Hallo KollegInnen,
hat jemand schon einen Viewer entdeckt, den man Mandanten empfehlen kann, um sich eine E-Rechnung anzusehen und auszudrucken 😉 (zum Beispiel zur Kontrolle der Lieferung).
Natürlich wird die E-Rechnung auch noch in UO hochgeladen, aber mir geht es um eine einfache und schnelle Erstansicht auch von Mitarbeitenden, die mit DUO nichts zu tun haben
Vielen Dank für Tipps, Fabian
Mir läuft gerade die erste digitale Ausgangsrechnung eines Mandanten über den Weg.
Eingespielt über die Dokumentenablage. Bei in Summe 15 -20 Belegen darunter 3-4 Ausgangsrechnungen pro Quartal ein vertretbarer Weg.
Die Rechnung lautet über 1190,00 Euro. Eine Positionen + USt. --> Eine Seite PDF.
Daraus werden in KaReWe 7 Seiten. Hintergrund der XML Teil wird visualisiert.
Warum werden Seitenweise leere Standardfelder mit visualisiert? über alle 6 Seiten Visualisierung verteilt findet man dann die auf der einen PDF-Seite dargestellten Werte.
gesamter Inhalt der ersten Hälfte Seite 5? Der Umsatzsteuersatz. 🙈
Bitte nicht falsch verstehen. Es ist richtig und wichtig den XML Teil darzustellen und zu prüfen. @andrereissig betont das zu Recht oft genug.
Nur wie wenig Mühe kann man sich bei der Visualisierung denn geben?
Wenn Feldwert = Null/leer dann lasse es in der Reihenfolge stehen sonst wenn Feldwert<> Null dann setze es nach vorne hinter das zuletzt verschobene Feld wenn kein Feld verschoben wurde Positionswert = 1.
Ja nicht sauber beschrieben und man müsste die Felder neu nummerieren,... das ließe sich aber programmieren.
Man könnte also dafür sorgen, dass alle Felder deren Wert ungleich Null sind auf den Seiten 1 und 2 der Visualisierung ausgegeben würden.
und warum man zwischen den Zeilen zwei oder sogar drei Leerzeilen braucht erklärt sich mir auch nicht.
Schön für die Lesbarkeit eine Leerzeile. Aber so viele?
Der hier kann zumindest visualisieren. Ob man dann drucken kann k.A. Aber ggf. ginge ja der Druck der Seite.
@VerenaWied schrieb:Der hier kann zumindest visualisieren. Ob man dann drucken kann k.A. Aber ggf. ginge ja der Druck der Seite.
Gilt leider nur für X-Rechnungen, nicht für ZUGFeRD.
@Gelöschter Nutzer schrieb:? bei mir wird leider nichts übernommen..... nur das übliche (Betrag, Rg.-Nummer etc.) und das teilweise auch falsch.
Das Programm erkennt überwiegend nicht mal Rg.-Datum und/oder Leistungsdatum - aber das nur nebenher.
Das mit den falsch übernommenen Werten aus E-Rechnungen kann ich bestätigen. Datev visualisiert zwar den XML Datensatz, übernimmt aber teilweise OCR-Werte aus der Sichtkomponente.
@andrereissig schrieb:Also ein Träumchen wäre ja ein Viewer, der beide Rechnungsbestandteile nebeneinander darstellt, links die XML, rechts die Sichtkomponente und man dann abschnittsweise die XML durchscrollen kann und dabei der Viewer parallel die Sichtkomponente analysiert und genau den entsprechenden Rechnungsteil in der Sichtkomponente hervorhebt.
[...]
Da könnte man doch sicher KI zielführend einsetzen, wenn die es einem schon ermöglicht, Gerichtsurteile in Gedichtform zusammenzufassen.
So hätte das Ergebnis ausgesehen, hätte man zur Abwechslung mal die Anwender gefragt was wir in unserer täglichen Berufspraxis wirklich brauchen.
@jjunker schrieb:und warum man zwischen den Zeilen zwei oder sogar drei Leerzeilen braucht erklärt sich mir auch nicht.
Schön für die Lesbarkeit eine Leerzeile. Aber so viele?
Ein möglicher Grund wäre, damit die Erfassung für Menschen so umständlich wie möglich wird und wir uns alle für den Automatisierungsservice Rechnungen entscheiden. Die neuen Cloud Anwendungen werden eben offenbar dieses Jahrzehnt nicht mehr fertig und man muss ja irgendwie an Geld kommen. Anders kann ich mir es nicht erklären.
So genug Ketzerei für heute.
@andrereissig schrieb:
Da könnte man doch sicher KI zielführend einsetzen, wenn die es einem schon ermöglicht, Gerichtsurteile in Gedichtform zusammenzufassen.
Aber doch nur Gerichtsurteile, die die KI selber erfunden hat. Man stellt eine Anfrage und die Asiaten am andern Ende der Leitung dürfen sich nicht lumpen lassen: https://taz.de/Amazon-Fresh-beendet-Just-walk-out/!5999230/
Man sollte ganz einfach die Neu-Technikgläubigen mit den tatsächlichen Kosten belasten, damit sie ihres Spaßes nicht plötzlich und unerwartet ledig werden, ohne die Hintergründe "einordnen" zu können: https://locusmag.com/2023/12/commentary-cory-doctorow-what-kind-of-bubble-is-ai/
Zumal es die KI im Fernsehsender ja nicht einmal schafft, den Inhalt des Teleprompters einer Nachrichtensendung fehlerfrei an den Bildschirm zu übertragen. Sollte die Transskription von E-Rechnungen nicht um Längen genauer ausfallen, sähe es mau aus mit dem Vorsteuerabzug.
@Gelöschter Nutzer schrieb:...
also wurschtelt man weiter so vor sich hin und braucht mehr Zeit wie früher, als man die Belege manuell erfasst hat.
Was anscheinend der Sinn hinter der KI ist.
(Zitat aus einem der vor verlinkten Artikel):
"... Cruise, the “self-driving car” startup that was just forced to pull its cars off the streets of San Francisco, pays 1.5 staffers to supervise every car on the road. In other words, their AI replaces a single low-waged driver with 1.5 more expensive remote supervisors – and their cars still kill people. ..."
Da ist KI im Rechnungswesen - zum Glück, möchte man sagen - bloß teuer und nervig, aber nicht auch noch tödlich.
@T_Ahmad schrieb:
@VerenaWied schrieb:Der hier kann zumindest visualisieren. Ob man dann drucken kann k.A. Aber ggf. ginge ja der Druck der Seite.
Gilt leider nur für X-Rechnungen, nicht für ZUGFeRD.
Wieso sollte ich auch eine ZUGFeRD Rechnung visualisieren? Da habe ich eine Sichtkomponente?!
Mich würde interessieren hierbei, sind die Daten auch bereits in der Belegbearbeitung in DUO falsch erkannt ?
Oder findet die falsche Erkennung nur im Rechnungswesen statt ?
@VerenaWied schrieb:Wieso sollte ich auch eine ZUGFeRD Rechnung visualisieren? Da habe ich eine Sichtkomponente?!
Weil der XML-Datensatz bei Abweichungen der maßgebliche Beleg ist und ich ein enormes Misstrauen gegenüber der praktischen Implementierung von ZUGFeRD habe.
Grundsätzlich hast du ja recht, die Sichtkomponente sollte eine Visualisierung ersetzen. Das klappt aber erst wenn wir eine automatische Validierung haben, die sicherstellt, dass die wesentlichen Werte (Insbesondere die Umsatzsteuer) nicht zwischen Sichtkomponente und XML abweichen.
So lange die Datev OCR Werte aus der Sichtkomponente zieht, statt den XML Anhang zu verarbeiten ist es also aus meiner Sicht unerlässlich anhand der XML-Visualisierung zu buchen. Wenn wir die XML-Werte in die Buchungszeile bekommen und das Programm signalisieren kann, dass die OCR Werte mit diesen übereinstimmen, entfällt dieser Zirkus natürlich.
@T_Ahmad schrieb:
@VerenaWied schrieb:Wieso sollte ich auch eine ZUGFeRD Rechnung visualisieren? Da habe ich eine Sichtkomponente?!
Weil der XML-Datensatz bei Abweichungen der maßgebliche Beleg ist und ich ein enormes Misstrauen gegenüber der praktischen Implementierung von ZUGFeRD habe.
Grundsätzlich hast du ja recht, die Sichtkomponente sollte eine Visualisierung ersetzen. Das klappt aber erst wenn wir eine automatische Validierung haben, die sicherstellt, dass die wesentlichen Werte (Insbesondere die Umsatzsteuer) nicht zwischen Sichtkomponente und XML abweichen.
Jo ok, wenn ich eine extra Prüfung brauche, ist das nicht möglich. Hier ging es ja aber um die reine Visualisierung für einen Mandanten (der wahrscheinlich einfach wissen will, was er zu bezahlen hat).
So lange die Datev OCR Werte aus der Sichtkomponente zieht, statt den XML Anhang zu verarbeiten ist es also aus meiner Sicht unerlässlich anhand der XML-Visualisierung zu buchen. Wenn wir die XML-Werte in die Buchungszeile bekommen und das Programm signalisieren kann, dass die OCR Werte mit diesen übereinstimmen, entfällt dieser Zirkus natürlich.
Ja stimme ich - nach allem, was ich hier gelesen habe - zu (ich buche nicht selber). Allerdings visualisiert Kanzlei-Rewe doch die XML Datei als erstes und packt die Sichtkomponente dahinter (zwar wohl nicht schön, aber Visualisierung ist da), dafür benötigst du doch nicht ein extra externes Tool?
@VerenaWied schrieb:
Jo ok, wenn ich eine extra Prüfung brauche, ist das nicht möglich. Hier ging es ja aber um die reine Visualisierung für einen Mandanten (der wahrscheinlich einfach wissen will, was er zu bezahlen hat).
Das ist jetzt natürlich eine Frage der Zuständigkeit. Wer prüft den Beleg auf Korrektheit? Der Mandant oder die Buchhaltungskraft beim Steuerberater? Wenn wir die Belegprüfung auf den Mandanten abwälzen (was ich für richtig halte, ich bin nicht das persönliche Sekretariat der Mandantschaft) muss der Mandant auch die XML-Datei visualisieren und mit der Sichtkomponente abgleichen.
Wenn der Abgleich erst in der Kanzlei erfolgt, reicht es natürlich die Sichtkomponente zur Überweisung heranzuziehen.
@VerenaWied schrieb:Ja stimme ich - nach allem, was ich hier gelesen habe - zu (ich buche nicht selber). Allerdings visualisiert Kanzlei-Rewe doch die XML Datei als erstes und packt die Sichtkomponente dahinter (zwar wohl nicht schön, aber Visualisierung ist da), dafür benötigst du doch nicht ein extra externes Tool?
Genau. Das Tool zur Visualisierung bräuchte ggf. der Mandant. Sofern er die Rechnungen nicht in Unternehmen Online visualisiert oder der Abgleich durch die Kanzlei erfolgt.
Wir bräuchten nur eine ordentlich durchdachte Visualisierung innerhalb der Datev-Programme...
Wir bräuchten nur eine ordentlich durchdachte Visualisierung innerhalb der Datev-Programme...
Wir haben ja eine durchdachte Visualisierung.
Die Felder werden in der Reihenfolge wie Sie in der XML vorhanden sind dargestellt.
Bleibt eben nur die Frage wie intelligent diese Herangehensweise ist.
Was mich nervt ist die Nichtübernahme der Kundennummer im xml Datensatz.
Wir haben einige Mandate bei denen in den Ausgangsrechnungen die Kundennummer dem Debitor entsprechen. Ich muss jetzt jedes mal erst zur "PDF-Rechnung" um den richtigen Debitor ansprechen zu können. 🤢
@Wuppergirl Wir haben das auch durchgehend eingefordert/ so angelegt das Debitor bei uns = Kundennummer beim Mandanten ist.
Eines unserer größeren Mandate schreibt E-Rechnungen. Bei 80-90 % wird der richtige Debitor vorgeschlagen.
Wo das System ins Stottern kommt ist bei Konzernkunden mit mehreren Kundennummern, abhängig vom Standort. Da kann System aber "nichts" für.
@jjunker sie werden mir auch vorgeschlagen, da wir die Mandate schon etwas länger betreuen und buchen. 😉
Was ich eben vermissen ist die Abbildung der Kundennummer im xml-Datensatz. Sie gehört für mich genauso da rein wie die Rechnungsnummer, das Datum und/oder der Rechnungsbetrag.
@Wuppergirl schrieb:Was ich eben vermissen ist die Abbildung der Kundennummer im xml-Datensatz. Sie gehört für mich genauso da rein wie die Rechnungsnummer, das Datum und/oder der Rechnungsbetrag.
Da liegt dann die Schuld wahrscheinlich beim ERP-System des Mandanten. Grundsätzlich sollte es im ZUGFeRD Standard möglich sein eine Kundennummer als XML-Wert zu definieren. Wenn diese im Datensatz vorhanden ist, jedoch die Datev den Wert nicht ausliest, liegt der Fehler bei der Datev.
Was grundsätzlich nicht schaden kann, ist die Kontonummer auch in das Feld Kundennummer der Debitorenstammdaten zu übernehmen (sofern noch nicht geschehen):
Sinnvoll wäre hier ein exportieren, in Excel bearbeiten und dann importieren. Vielleicht hilft das.
Was ich eben vermissen ist die Abbildung der Kundennummer im xml-Datensatz. Sie gehört für mich genauso da rein wie die Rechnungsnummer, das Datum und/oder der Rechnungsbetrag.
👍
Hallo @jjunker,
wir arbeiten aktuell an einem Visualisierungsservice in Unternehmen Online, mit dem sich die Ansicht der E-Rechnung verbessern wird.
Infos bezüglich dem genauen Zeitpunkt der Visualisierungskomponente gibt es dann über DATEV myUpdates 🙂
In Kanzlei-Rechnungswesen wurde der Visualisierungsservice in der Jahreswechselversion ausgeliefert.
@Sarina_Schug: Danke für Ihre Antwort.
In Kanzlei-Rechnungswesen wurde der Visualisierungsservice in der Jahreswechselversion ausgeliefert.
Genau dieser Service ist lieblos und einfallslos programmiert worden. Eine einseitige PDF Rechnung wird mit 6 Seiten Visualisierung ergänzt. --> Das würde ich ein deutliches Missverhältnis nennen.
Hallo @Sarina_Schug ,
ist denn eine Überarbeitung der E-Rechnungsvisualisierung im Kanzlei-Rechnungswesen zu erwarten? Auf die Fehler des Programms wurde in der Community nun mehrfach hingewiesen. Ebenso wurden Verbesserungsvorschläge geliefert. Und wird der Visualisierungsservice im Unternehmen Online genauso (schlecht) umgesetzt werden?
Ich bitte um Entschuldigung für diese direkte, unverblümte Frage, aber aktuell halte ich (sicherlich nicht als einziger) die Arbeit mit E-Rechnungen im Datev-Ökosystem für unzumutbar.