@-Kila-  schrieb: Und da wir noch alles ausdrucken, drucke ich nun die 8 Seiten aus, oder das PDF? Hier wäre eine gute Gelegenheit gewesen, dass der Entscheidungsträger dieses Vorgehen gründlich überdenkt. Das Ausdrucken von E-Rechnungen halte ich für sinnbefreit, da sie damit den Belegcharakter verlieren. Aber nicht meine Baustelle.   @sokleinmitHut  schrieb: Alles ausdrucken: Sichtkomponente, Datenvisualisierung und xml-Datei. Sicher ist sicher. Weder Sichtkomponente, noch die Visualisierung oder die rohe XML-Datei, da elektronische Rechnungen grundsätzlich im elektronischen Original zu archivieren sind. Sicherheitshalber ausdrucken ist aus meiner Sicht nur eine Arbeitsbeschaffungsmaßnahme die keinerlei Sicherheit bringt.   Wenn man sich die Rechnungen (aus welchem Grund auch immer) für sich selbst ausdruckt und damit zu wertlosen Rechnungskopien macht, ist es Geschmackssache was man ausgedruckt haben möchte. Wahrscheinlich am ehesten die Sichtkomponente, nachdem geprüft wurde das keine Abweichung zum Datensatz besteht.   @-Kila- am besten fragst du da deinen Chef wie du vorgehen sollst und wenn er dich fragt wie es denn am besten ist, kannst du ihm anhand des verlinkten BMF-Schreibens erklären warum das Ausdrucken von Rechnungen nicht mehr zeitgemäß ist. ... Mehr anzeigen

@-Kila-  schrieb: 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? Kommt ganz drauf an: Ist die XML-Datei eine X-Rechnung und erfüllt somit die Anforderungen an eine E-Rechnung?   Man könnte in dem Fall zu der Auffassung kommen, dass wir zwei Rechnungen haben: 1. Die PDF-Datei als sonstige Rechnung 2. Die XML-Datei als E-Rechnung   Ungeachtet dessen, dass u. U. doppelt Umsatzsteuer geschuldet werden könnte (was durchaus fraglich ist, die BPs der nächsten Jahre, bzw. ggf. die darauf folgenden FG-Prozesse, werden es zeigen) rate ich dringend davon ab doppelt Vorsteuer zu ziehen.   Wenn die XML-Datei keine vollwertige E-Rechnung ist, dann ist die PDF als sonstige Rechnung hochzuladen. Wenn wir eine X-Rechnung haben, würde ich nur diese hochladen und buchen. Im Anschluss würde ich dem Rechnungsaussteller einen Vortrag über die E-Rechnung und das dazugehörige BMF-Schreiben halten. Beides hochladen halte ich für gefährlich.   Grundsätzlich sollte man hier den Chef und/oder zuständigen Steuerberater fragen, welches Vorgehen gewünscht ist. Eben die Person die am Ende mit der eigenen Unterschrift für eventuelle Fehleinschätzungen gerade stehen muss. Leider scheint es mir, als ob den Entscheidungsträgern manchmal das notwendige technische Verständnis fehlt um das rechtlich einwandfreie Wissen auch in die Praxis umzusetzen.   Wenn eine XML-Datei (=Anhang) nicht in deiner PDF-Datei (=Container) eingebunden ist haben wir jedenfalls keine ZUGFeRD-Rechnung.    Randnummer 4 des BMF-Schreibens:   Das strukturierte elektronische Format einer elektronischen Rechnung [...] • kann zwischen Rechnungsaussteller und Rechnungsempfänger vereinbart werden. In Verbindung mit Randnummer 63: Die Zustimmung des Empfängers zu der Rechnungserteilung in einem anderen elektronischen Format (vgl. Rn. 20) bedarf keiner besonderen Form. Es muss lediglich Einvernehmen zwischen Rechnungsaussteller und Rechnungsempfänger über das zu verwendende Format bestehen. Die Zustimmung kann etwa in Form einer Rahmenvereinbarung (z. B. in den Allgemeinen Geschäftsbedingungen) oder konkludent erfolgen. Sollte man in dem Zusammenhang auch beachten. ... Mehr anzeigen

@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: 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    ... Mehr anzeigen

@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. ... Mehr anzeigen

@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.     ... Mehr anzeigen

@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.   ... Mehr anzeigen

@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? ... Mehr anzeigen

@andreashofmeister  schrieb: @prudentius  schrieb: was mir dazu noch einfällt:    Sobald man doch nach paar Minuten weiter arbeiten will, wurde man automatisch ausgeloggt. OK gut, aber warum ist da kein Button um sich wieder einzuloggen?? Ich soll mein Browser neu starten?? Nein. ich muss nur die Seite neu laden. UX wieder fürn Eimer. Grundsätzlich immer noch besser, als dass jemand unberechtigtes Zugriff hätte....   Es ist nervig, aber mit F5 kann man das einfach beheben. Sicherheit ist nie schön und performant...     Sicherheit kann durchaus schön und performant sein. Und vor allem konsequent in der Umsetzung.   Manchmal wird man raus geschmissen, weil man zwei Minuten keine Eingabe getätigt hat, ein anderes Mal wird der Browser geschlossen und viel später neu gestartet und man ist noch eingeloggt. Ich habe da noch kein logisches Muster erkennen können, nach welchem Kriterium entschieden wird, ob man ausgeloggt wird. Außer vielleicht, dass man ständig raus fliegt, wenn man mehr als einen Tab mit einer Datev Anwendung auf hat.  ... Mehr anzeigen

Ironischerweise funktioniert an dieser Stelle das automatische ausfüllen bekannter Adressdaten im Edge Browser, was ja irgendwie fehleranfälliger ist, als das kopieren und Einfügen. ... Mehr anzeigen

Hallo @Kristin_Frohmeyer    ist mit einer Umsetzung in LODAS noch zu rechnen? Und falls nicht, wurde dieser Wunsch an die Entwicklungsabteilung der neuen Cloud basierten Lohn Anwendung weitergegeben? ... Mehr anzeigen

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

@glasi  schrieb: Du gehst nicht über Mydatev Mandantenregistrierung im Arbeitsplatz?  Die Freude über deinen Tipp war von kurzer Dauer:   Statt probieren Sie es später, probieren Sie es am nächsten Tag. 💀 ... Mehr anzeigen

@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.      ... Mehr anzeigen

Oh wow... Danke für den Tipp. Das scheint ja durchaus mal eine durchdachte Datev Lösung zu sein. ... Mehr anzeigen

Ich wollte heute die nächste Charge Unternehmen Online für Mandanten bestellen. Meine Direktlinks zur Bestellseite funktionieren nicht mehr, da der Shop überarbeitet wurde. Ist ja auch in Ordnung.   Was nicht in Ordnung ist, dass ich beim Anlegen einer (mandantengenutzten) Beraternummer nun E-Mail Adressen nicht mehr per Copy & Paste einfügen kann sondern zwei mal abtippen muss, was ironischerweise fehleranfälliger ist, da ein vergessenes Satzzeichen gerne auch beim zweiten mal eingeben vergessen werden kann. Ebenso muss ich mich jetzt stück für Stück durch das Formular klicken, statt alles auf einer Seite einzugeben. Und nun bei der zweiten Bestellung sind ALLE Felder noch mit den Daten der vorherigen Bestellung vor belegt und müssen ersetzt werden. Also darf ich immer schön kontrollieren ob auch alle Daten stimmen und nichts vergessen wurde.   Der Prozess hat sich jetzt vom zeitlichen Aufwand verdoppelt. Dafür habe ich ein schickeres Design. Die Datev weiß wohl ihre Prioritäten zu setzen. Die Ladezeiten zwischen den ganzen zusätzlichen Klicks nicht mit einberechnet. Ebenso wenig wie das ständige neu Laden und kontrollieren, weil gefühlt jeder dritte Klick dazu führt, dass ich abgemeldet werde:   Beim Anlegen der Personendaten dann wieder das gleiche Spiel mit den E-Mail Adressen, bevor man dann zwei mal die AGBs bestätigen muss. Reicht ja nicht, dass der direktlink zur Zustimmung zum mitgliedsgebundenen Mandantengeschäft nur bei jedem zweiten Mal funktioniert und ich aufgrund der E-Rechnungsvisualisierung nun deutlich länger für die laufenden Buchhaltungen brauche.   Macht die Datev eigentlich einen Testlauf ihrer eigenen Produkte, bevor diese auf uns los gelassen werden? Für mich fühlt es sich an, als würde man in Nürnberg versuchen möglichst viele in eine Umschulung zu mobben.   ... Mehr anzeigen

@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. ... Mehr anzeigen

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

@AGerstner  schrieb: Weiß jemand wie ich das korrigieren kann?   Danke für Hilfe. Eine erneute Übergabe des Kassensaldos ist nicht vorgesehen, daher müsste zum 01.01. eine Kassenbewegung über die Differenz erfasst werden. ... Mehr anzeigen

@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. ... Mehr anzeigen

@unklarer_Posten  schrieb: Wir haben es ursprünglich in unserem ERP so gelöst, dass sowohl Zugferd (pdf+xml) sowie X-Rechnung (xml) parallel verschickt wurden, sodass der Kunde sein Lieblingsformat wählen kann. Ist aus meiner Sicht auch nicht richtig so, da dadurch zwei Rechnungen für eine Leistung entstehen und im Zweifelsfall doppelt Umsatzsteuer geschuldet werden könnte. Wenn die Gegenseite fälschlicherweise beide Rechnungen verarbeitet und doppelt Vorsteuer zieht, könnte das Finanzamt Sie für den Schaden haftbar machen. (Keine Steuerberatung, ich knabber Wachsmalstifte)     ... Mehr anzeigen

@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... ... Mehr anzeigen

@m_brunzendorf  schrieb: Schaut man sich dafür beim Verbuchen nicht den Beleg an?   Dann sollte man doch sehen, dass bei der Belegverbuchung aus der xml-Datei z.B. 1.000,00 Euro übernommen wurden aber der Sichtbeleg nur 100,00 Euro. Ja, würden die Werte konsequent aus der XML Datei übernommen werden, könnte man die Buchungszeile einfach mit der Sichtkomponente abgleichen. Leider ist das aktuell nicht der Fall. Da Werte aus der Sichtkomponente übernommen werden, muss also ein Abgleich mit der XML Visualisierung vorgenommen werden um Gewissheit zu haben.   Ist das absolut unsinnig? Ja. Kostet uns das wertvolle Zeit, die wir nicht haben? Ja. Hat sich die Datev dafür Arbeit gespart? Ja.   Das ist eben das Ergebnis, wenn man in letzter Minute irgendwas zusammen programmieren lässt, von Leuten die absolut keine Ahnung von den praktischen Anforderungen an die Software haben. Ist leider keine Ausnahme. ... Mehr anzeigen

@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. ... Mehr anzeigen

@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. ... Mehr anzeigen

@Renate-2025  schrieb: Doch dann könnten vermutlich in der einen andere Inhalte stehen, als in der anderen und das wäre wiederum eine Einladung für Lug und Trug ... Ironischerweise kann auch bei ZUGFeRD etwas anderes in der XML stehen, als in der PDF-Sichtkomponente. Die Einladung für Lug und Trug ist also trotzdem gegeben. Daher empfiehlt es sich immer anhand der XML-Daten zu buchen, da diese rechtlich Vorrang haben. ... Mehr anzeigen

@VerenaWied  schrieb: Der hier kann zumindest visualisieren. Ob man dann drucken kann k.A. Aber ggf. ginge ja der Druck der Seite. ELSTER 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. ... Mehr anzeigen

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

@deusex  schrieb: Wir sollten uns hier wirklich mal von der BMF-Theorie lösen, wie das DATEV umsetzt und "über den Zaun schauen" oder andernfalls wir müssen wohl die FiBu-Gebühren um 300% erhöhen und Personal einstellen, das es nicht gibt . . . aber zumindest hilft uns die Regierung wenigstens dabei mit ihrer Deindustrialisierungs-Strategie, dass wieder bald mehr Personal für Steuerkanzleien und Mandantenbuchführungen verfügbar ist ... dumm nur, dass es dann wieder keine Buchhaltungen dazu gibt  . . . egal, ich schweife ab. Eigentlich (!) sollte die E-Rechnung uns Arbeit abnehmen, da alles was maschinenlesbar ist nicht mehr abgetippt und im Falle von OCR, geprüft werden müsste. Eigentlich. Grundsätzlich hätte man durch die strukturierten Daten eine Möglichkeit schaffen können, den Kompletten Prozess der Rechnungserfassung nach und nach zu automatisieren, indem man Lerndateien auf Einzelpositionsbasis zur Aufteilung von Rechnungen erfasst. Wer aber eine E-Rechnung in der Buchungszeile hat und auf Lerndatei anlegen klickt bekommt die Meldung, dass keine Belegdaten vorhanden seien. (da keine Vorerfassung im Bearbeitungsmodus Erweitert im Unternehmen Online erfolgt ist.) Somit lassen sich bei nicht aufzuteilenden Rechnungen nicht mal Lerndateien anlegen.    Ich würde gerne behaupten können, die Datev würde uns hier nicht mit Absicht das Leben schwer machen um zum buchen des Automatisierungsservice Rechnungen zu drängen, (welcher bislang auch nichts komplexeres als eine Lerndatei anzulegen scheint) aber dazu fehlt es mir leider an Argumenten.   TLDR: Wir haben alle notwendigen Daten um unseren Arbeitsaufwand zu dritteln, die Datev sorgt aber, ganz im Sinne des Wirtschaftspolitischen Zieles des Vollbeschäftigung dafür, dass sich unser Arbeitsaufwand verdreifacht.   OT: Tolle Anmerkung zu unserer Bundesregierung. Die Datev ist ähnlich kompetent und die "Alternative"(n) scheinen auf manchen wie eine bessere Lösung zu klingen, sind aber praktisch der selbe Müll in Blau, ähhhh grün. So jetzt ganz schnell abmelden bevor es zu politisch wird....   LG TA     ... Mehr anzeigen

Einfacher ja, richtig nein, da dies nicht dem ZUGFeRD-Standard entspräche. Wir haben hier ein Hybrides Dateiformat welches die XML-Rechnung in einem PDF Container mit Sichtkomponente verpackt. Alternative wäre eine X-Rechnung welche nur aus einer XML-Datei besteht und ein Programm benötigt um lesbar gemacht zu werden.   Wieso sollte man wissen wo der maschinenlesbare Teil der Rechnung zu finden ist? Das menschliche Auge kann damit sowieso nicht viel anfangen. Einfach mal den XML-Anhang öffnen, dann verstehst du was ich meine. ... Mehr anzeigen

@Moonshine  schrieb: Alkohol Ist uns Muselmanen leider nicht erlaubt. Und stört mein empflindliches Darmbiom. 😢   @Moonshine  schrieb: Schokolade... Jeden morgen 5g, 100%ige Bio Schokolade. Ist zwar Schweine (Haram! hihi) teuer, aber anders hält man es nicht aus. ... Mehr anzeigen