Falls es Jemanden interessiert, ich habe unseren Import jetzt über Microsoft Power Automate gelöst. Ist sicherlich nicht schön, aber funktioniert jetzt wenigstens vollautomatisch.     ... Mehr anzeigen

@siro  schrieb:   Ich würde einen Blick auf die Datenservices Rechnungswesen werfen Kurzer Nachtrag zum DATEV Rechnungsdatenservice: der Rechnungsdatenservice ermöglicht keine automatisierte Übertragung von Daten. Vor jeder Übertragung muss OAuth2 mit Unternehmen Online ausgeführt werden. Das bedeutet auf Deutsch: jedes Mal, wenn man Daten mit Rechnungsdatenservice übertragen möchte, muss sich ein Menschen mit mindestens SmartLogin anmelden und der ausgestellte Token ist nur 15 Minuten gültig.   Damit gibt es ganz offensichtlich bei DATEV, bis auf Mail Upload mit vorbenannten Einschränkungen, überhaupt keine Möglichkeit Belege vollautomatisch zu importieren. ... Mehr anzeigen

@metalposaunist  schrieb: Alright 💪! Wieder was gelernt 🤓. Ihren Beitrag speichere ich mal für die Zukunft ab 😊. Danke! Gern geschehen und Danke für die Unterstützung! 😊   Wichtig hinzuzufügen wäre mir noch, dass durch die beschriebene Tatsache grundsätzlich keine E-Mails aus den Netzen von Amazon Web Services, Microsoft Azure oder Google Cloud Platform versendet werden können. Die dort vorhandenen oder empfohlenen E-Mail-Dienste arbeiten alle als Relay und verwenden entsprechend das, was hier als "Umleitung" beschrieben wird (Relaying). Das Verwenden eines anderen, externen Mailservers ist grundsätzlich nicht möglich, da die meisten Cloud-Anbieter und auch RZs den SMTP-Port, richtigerweise zur Spam-Abwehr und Reputationssicherung, sperren.   Das hat zur Schlussfolgerung, dass es keinerlei Möglichkeit für moderne Software-Anwendungen gibt, Rechnungen automatisiert an DATEV zu übermitteln ohne vorher ein aufwändiges Prüf- und Zertifizierungsverfahren bei DATEV durchlaufen zu müssen. Sofern dies überhaupt gestattet wird. Der Belegtransfer ist eine Win64-Anwendung ohne dokumentierte APIs und der Rechnungsdatenservice erfordert eine, wie auch immer geartete, Zertifizierung. ... Mehr anzeigen

@metalposaunist  schrieb: Der Unterschied zwischen umleiten und weiterleiten ist Dir aber bewusst? Ich habe den Hilfe Center Eintrag auch noch nicht ganz verstanden aber als Tipp:    Wenn Du umleiten einstellst, wird der E-Mail Header nicht umgeschrieben und landet 1:1 bei DATEV, wobei DATEV den ablehnt. Heißt: E-Mail kommt von kunde@kunde.de und wird an rechnung@lodgea.de geschickt und Du stellst eine Umleitung von rechnung@lodgea.de an uploadmail@datev.de ein, so landet kunde@kunde.de bei DATEV.    Um das zu umgehen nutzt man weiterleiten, weil dann als Header rechnung@lodgea.de in der E-Mail steht, die bei DATEV autorisiert wurde.    Ich hoffe, ich habe das jetzt nicht verdreht aber wenn ich Mails umleite, werden die Mails 1:1 so wie sie geschrieben worden sind z.B. per Regel einem anderen Postfach zugestellt und dort steht der Absender des "echten" Absenders drin. Beim Weiterleiten steht im Falle von E-Mail Regeln immer das Empfängerpostfach drin, dass weiterleitet; die eigentliche Absenderadresse erscheint aber auch im Outlook nicht mehr.  Entschuldigen Sie bitte, dass ich jetzt technisch etwas konkreter werden muss und Sie hier korrigiere, bitte nicht persönlich nehmen. Der sog. "Envelope Sender" ist keine Kopfzeile (engl. "Header"), sondern das MAIL FROM Kommando im SMTP-Handshake. Umleitungen oder Weiterleitungen (sind nach RFC am MTA identisch) beinhalten immer den Originalen Sender des Umschlags (engl. Envelope).   Einige Agenten (Mail-Agents wie z.B. Outlook, iMail etc.) bieten die Möglichkeit die E-Mail als "Forwarding" (Weiterleitung) an einen anderen Nutzer zu senden. Dabei wird die E-Mail jedoch nicht weitergeleitet, sondern als neuer Umschlag (Envelope) mit einer Köpie der Anhänge (Mime-Multiparts bzw. Attachments) sowie dem Körper (entsprechende HTML/Text Multiparts) versendet. Das ist rein die Sache des Mail Agent und Outlook.com bietet als web-basierter Mail-Agent das eben auch als Regel an.   Weil eben technischer Versender und Versender in den Kopfzeilen ("From"-Header) häufig nicht identisch sind, gibt es ja eben SPF und DKIM zur teilweisen, aber ausreichenden Überprüfung der Identität. Der korrekte Weg von DATEV wäre hier: Empfang der E-Mail, Überprüfung des FROM-Headers und Prüfung des MX oder SPF im DNS sowie entsprechend DKIM falls vorhanden.   So wie das von DATEV aktuell implementiert ist, muss man feststellen: Umleiten oder Weiterleiten von E-Mails gemäß entsprechender RFCs ist bei DATEV Upload Mail grundsätzlich nicht möglich. ... Mehr anzeigen

@siro  schrieb: Ich dachte eigentlich daran aus der Anwendung direkt via Exchange Online zu senden, und nicht erst nach ExOn und dann nach Datev. Das geht leider nicht. Die Exchange Online API erfordert OAuth für das Postfach und über SMTP/TLS geht natürlich und richtigerweise aus AWS heraus nicht. ... Mehr anzeigen

@siro  schrieb:   Exchange Online Plan 1 mieten Erfreulicherweise haben wir bereits Exchange Online.   Ich habe in Exchange-Online entsprechend dieser Empfehlung in der DATEV-Hilfe eine Mail-Flow-Regel erstellt: https://apps.datev.de/help-center/documents/1007550 (Punkt 2.4: Microsoft 365)       Das Ergebnis ist leider das Folgende. Die E-Mail wird von DATEV zurückgewiesen. Die Absender sind jedoch alle in DUO für Mail Upload per Double-Opt-In freigeschaltet.   Für etwaige Hinweise wäre ich sehr dankbar, da wir bereits mehrere Tage Entwicklung haben einfließen lassen und Ich mittlerweile nicht mehr weiter weiß.   ... Mehr anzeigen

@jankammerath: Dann habt Ihr einen StB, der Euch betreut? Dann hat dieser StB bei DATEV einen KV (Kundenverantwortlichen), bei dem ich das Ganze mal eintüten würde, wie man Euch da helfen kann bzw. wie man aus der Lage am besten ohne viel Aufwand kommt.  Ja, hat unser Steuerberater dort bereits angefragt. ... Mehr anzeigen

@vogtsburger  schrieb:   Sie möchten also sämtliche Ausgangsrechnungen einer Zimmervermietungs- oder -Vermittlungs-Plattform über Datev-Upload-Mail abwickeln? Oder sind es nur die Provisionsabrechnungen an die Vermieter?   Unsere Kunden zahlen eine monatliche Gebühr per Lastschrift oder Kreditkarte. Hierfür erstellt unsere Software eine Ausgangsrechnung, welche wir automatisiert in DATEV importieren müssen. Das Übersenden per E-Mail würde hierfür vollkommen ausreichen.     @vogtsburger  schrieb:   Mich würde interessieren, warum man nicht den 'offiziellen' Weg über ein Registrierung und Zertifizierung bei der DATEV geht. Sind die Kosten für das Datev-Consulting und für die Zertifizierung das Hindernis ? Der Prozess erwartet 3 DATEV-Referenzkunden sowie deren Steuerberater. Wir wollen die Schnittstelle jedoch ausschließlich für den Hausgebrauch einsetzen und derzeit besteht bei keinem unserer Kunden ein irgendwie geartetes Interesse an dieser Schnittstelle.     @vogtsburger  schrieb: Wenn doch das Business 'groß' gemacht werden soll/will, sollten doch solche Kosten und Vorgaben eines Dienstleisters mit einkalkuliert werden, oder? Kosten für DATEV sind einkalkuliert. Ein zusätzliches ERP-System ist nicht einkalkuliert und ergibt auch unternehmerisch derzeit keinen Sinn. ... Mehr anzeigen

@siro  schrieb:   Ich würde einen Blick auf die Datenservices Rechnungswesen werfen   https://www.datev.de/web/de/loesungen/steuerberater/klassisches-kanzleigeschaeft/belege-und-daten-digital-in-die-kanzlei-uebertragen/datenservices-rechnungswesen/ Danke für den Tipp. Den habe ich mir auch bereits vor Monaten angesehen und auch die API-Dokumentation dafür liegt mir vor (DATEV Developer Portal). Einzig erfordert DATEV hierfür einen, nicht näher beschriebenen, Zertifizierungsprozess als Partner. Wir möchten aber gar kein DATEV-Partner werden, weil das weder für DATEV noch für uns als Unternehmen sinnvoll erscheint. Möchten wir doch lediglich unsere eigenen Ausgangsrechnungen übertragen.   Die bestehenden DATEV-Partner für den DATEV Rechnungsdatenservice 2.0 habe ich mir auch angesehen, aber das sind alles vollwertige ERP-Systeme. Wir brauchen jedoch keines dieser ERP-Systeme und planen deren Einsatz auch nicht. ... Mehr anzeigen

@metalposaunist  schrieb: @reiz schrieb: Der DATEV Kundensupport hat sich mit mir in Verbindung gesetzt und mir mitgeteilt warum die E-Mails die via AWS SES versandt wurden, abgelehnt wurden. Die Grund war/ist das der "envelope sender" nicht mit der "from" Adresse übereinstimmt. Ah, okay! Wieder was gelernt. Hat DATEV auch gesagt, warum das wichtig ist bzw. DATEV so macht? Da DATEV mit DATEVnet ja etliche Exchanges betreibt und selbst den 0 Spamkurs fährt, würde mich interessieren, wer von beiden sich ggf. nicht an IT Standards hält, die der Sicherheit beitragen.    Erstmal riesen großen Dank für diesen Beitrag. Wir kämpfen seit über 6 Monaten mit dem Problem und das hat bei uns heftige Kosten verursacht. Wenigstens kennen wir jetzt den Hintergrund.   Wir sind ein Software-as-a-Service (SaaS) Unternehmen und haben unsere Software so programmiert, dass die Rechnungsstellung die Dokumente über AWS SES automatisch an DATEV sendet. Dass DATEV sich nicht an die internationalen Standards für E-Mail-Versand hält und das auch nirgendwo dokumentiert, ist natürlich eine herbe Enttäuschung.   Wir sind auf Gedeih und Verderb darauf angewiesen, dass unsere Dokumente automatisch bei DATEV landen und stehen jetzt mit dem Rücken zur Wand.   Was sind Eure Lösungsansätze bzw. wie habt Ihr das Problem nun gelöst?   Nochmal Danke und viele Grüße,   Jan ... Mehr anzeigen