Vll. wäre es mal an der Zeit das sich jemand von @DATEV selbst hier zu Wort meldet ...... @
10 Beitragsschreiber - 10 unterschiedliche Sachverhalte
Hier hilft aus meiner Sicht nur die individuelle Prüfung durch den Service.
Hallo Herr Balser,
was ist denn ein zusätzlich gesichertes Login?
"Vor ca. 1 Woche haben wir zu den Zugang zum Konto über die Webseite der Deutschen Bank ein zusätzlich gesichertes Login eingerichtet (gem. PSD2)."
Gruß
Im Fall der Deutschen Bank gibt es zwei Möglichkeiten welche nun - zusätzlich zur Eingabe der PIN - notwendig sind, um auf das Konto zuzugreifen: photoTan oder mobileTan. Die Option zur Umstellung bekommt man beim Login zum Online-Konto.
Moin in die Runde,
also ich bin Mandant/Anwender und uns hat es gestern "erwischt". Das UO Banking Modul zwang zu einer Umstellung.
Grundsätzlich - weil es ja hier auch um positive Erfahrungen ging - hat alles ganz easy geklappt, Umstellung auf finAPI eines Deutsche Bank Kontos.
Nun ist es erstmal ärgerlich, dass z.B. Sammelüberweisungen (bei uns üblicherweise Löhne), aber aktuell viel schlimmer Auslandsüberweisungen nicht mehr gehen. Wir überweisen täglich diverse Rechnungen in alle Erdteile und wer das schon mal gemacht hat ist froh, wenn man die Beleg vorab erfassen kann und dann ganz einfach aus dem Beleg die Zahlung initiiert - Ich bin gespannt was die DB dazu beträgt und frage mich an dieser Stelle, wer eigentlich hier in diesem Zusammenspiel mit der DATEV tatsächlich einen klärenden Hut auf hat.
Für mich ist PSD2 derzeit der größte Rückschritt in die digitale Steinzeit und wiederum ein Beispiel für haufenweise Inkompetenz der Politik.
In dem Sinne.
Gruß aus dem Norden
T.
Guten Morgen, ich bekomme richtig Bauchweh wenn ich all das hier lese.
Guten Morgen,
und man wird wieder bestätigt, dass man nicht jede Software gleich nach Erscheinen installieren soll, aber wenn man wie hier dazu gezwungen wird.
Von DATEV habe ich seit vorgestern Mittag nichts mehr gehört.
Gruß
Ist eventuell denkbar, dass beim Umzug auf die FinApi-Schnittstelle nicht das persönliche Authentifizierungsmedium (Datev mIdentity, SmartLogin, SmartCard) des betroffenen HBCI-Nutzers genutzt wurde, sondern jemand anders die die Migration durchgeführt hat?
Lt Datev muss die Umstellung ja "pro HBCI-Benutzer von jedem Berechtigten für den eigenen HBCI-Zugang unter Verwendung des eigenen Authentifizierungsmediums durchgeführt werden."
Moin, trifft hier nicht zu, gibt nur einen Benutzer und das bin ich.
Also unser Mandant hat nun erfolgreich auch sein letztes Konto bei der Deutschen Bank umgestellt und auch bereits Überweisungen getätigt. Sammelüberweisungen scheinen zu funktionieren ...
Mandant nutzt PhotoTan
Hallo zusammen,
wir kennen den Fehler und analysieren ihn gerade.
Bei dieser Fehlermeldung kann es an Browsereinstellungen liegen. Wir haben bis jetzt die Erfahrung gemacht, dass die Migration mit dem Browser Google Chrome funktioniert.
Sollte dies nicht funktionieren, setzen Sie sich bitte über Servicekontakt mit unserem Programmservice zur weiteren Analyse in Verbindung.
mit freundlichen Grüßen
Uschi Brandenburg
Produktmanagement Zahlprozesse
Hallo Herr Vogtsburger,
es konnten sich bereits über 9.000 Anwender erfolgreich bei finAPI migrieren.
Mit freundlichen Grüßen
Uschi Brandenburg
Produktmanagement Zahlungsverkehr
Hallo Frau Brandenburg,
Danke für die Rückmeldung.
Habe es mit Google Chrome sowie Internet Explorer 11 versucht, mit jeweils dem gleichen Ergebnis.
Einen Servicefall dazu gibt es seit Mittwoch: Vorgang 2421682
Mit freundlichen Grüßen
Ludger Naber
Hallo Frau Oudshoorn,
wann tritt denn die PhotoTAN in Aktion ?
... nur beim Online-Banking auf dem Mandanten-PC (per Browser-Login oder per Banking-Software) oder auch bei Umsatzabrufen und/oder Zahlungen über Datev ?
VG
Michael Vogtsburger
Hallo Herr Laber,
vielen Dank für die Information, ich melde mich persönlich bei Ihnen
Hallo an alle,
nun ich auch mal:
Setzen Datev bei uns im Unternehmen ein (eigener Quasi-Server).
Bank: Sparkasse (HBCI mit pushTAN)
Migration: OK
Umsätze abholen: OK
Sammel-LS einreichen: OK (sind tatsächlich eingezogen worden)
Einfache Überweisung tätigen: (PIN und TAN-Medium werden NICHT abgefragt, vielleicht noch im Speicher hinterlegt?) => Fehler (Fenster "Logbuch-Details" von Datev):
16.08.2019 16:08:40 Der DFÜ-Auftrag wird an das DATEV-Rechenzentrum übertragen.
16.08.2019 16:08:44 Der DFÜ-Auftrag wurde an das DATEV-Rechenzentrum übertragen.
16.08.2019 16:08:44 Der DFÜ-Auftrag wird an die Bank übertragen.
16.08.2019 16:08:45 Der DFÜ-Auftrag konnte nicht an die Bank übertragen werden.
16.08.2019 16:08:45 ZVCONS0000001:
Sammel-Ü: (PIN und TAN-Medium werden abgefragt!!) => Fehler im WebForm-Fenster:
Kommunikationsprotokoll
{ "error": "ZVCONS0000002", "additional_messages": [ { "description": "Ticket: 2019-08-16 2SXGH\nCannot assign to fintsorder", "severity": "error", "affected_fields": [] } ] }
Danach Fenster Logbuch-Details:
16.08.2019 16:09:33 Der DFÜ-Auftrag wird an das DATEV-Rechenzentrum übertragen.
16.08.2019 16:09:34 Der DFÜ-Auftrag wurde an das DATEV-Rechenzentrum übertragen.
16.08.2019 16:09:34 Der DFÜ-Auftrag wird an die Bank übertragen.
16.08.2019 16:11:18 Der DFÜ-Auftrag wurde an die Bank übertragen.
16.08.2019 16:11:22 Der DFÜ-Auftrag konnte nicht an die Bank übertragen werden.
Interessant ist, dass es mal Fehler ZVCONS0000001 und mal ZVCONS0000002 ist. Das eine Mal erscheint er im Logbuch, das andere mal nicht, dafür aber im WebForm-Fenster zuvor.
Ich vermute ganz stark Sand im Getriebe zwischen finAPI und S-Rechenzentrum. Ich halte das ganze für ziemlich unausgegoren und mit einer relativ heißen Nadel gestrickt. Auf der einen Seite ein recht junges FinTech-Unternehmen, auf der anderen Seite X Banken und deren Rechenzentren. Da prallen Welten aufeinander. Und wer mal mit den Rechenzentren und Bank-IT zu tun hatte, weiß, wie schwierig das werden kann.
Beste Grüße
Haller
Hallo Herr Haller,
wir haben uns für den Kooperationspartner finAPI aus dem Grund entschieden, da es sich dabei um ein seit 2009 auf dem Markt befindliches Unternehmen handelt, das bereits über große Erfahrung als Zahlungsauslöse-/Kontoinformationsdienst verfügt.
Um die von Ihnen geschilderte Fehlermeldung genauer analysieren zu können, bitte ich Sie sich mit unserem Programmservice direkt in Verbindung zu setzen.
Vielen Dank
Mit freundlichen Grüßen
Uschi Brandenburg
Produktmanagement Zahlungsverkehr
Hallo Frau Brandenburg,
Danke für das Telefonat und Fernwartung, hoffe Sie kommen dadurch dem Problem auf die Spur.
Mit freundlichen Grüßen
Ludger Naber
Guten Morgen Herr Vogtsburger,
unser Mandant macht Überweisungen über DUO mit der PhotoTan.
Umsatzabrufe macht er nicht, auch ein anderes Bankingprogramm nutzt er nicht.
Die Bankkontoumsätze holen wir aus dem Rechenzentrum.
Gruß
Ina Oudshoorn
Guten Morgen Herr Haller,
konnten Sie das Problem lösen? Wir haben nun auch den Fehler ZVCONS0000002 bei den aus Datev bereitgestellten Lohn-Überweisungen.
Gruß
Ina Oudshoorn
Hallo,
der Fehler tritt nach unseren Erkenntnissen in der Regel bei Terminüberweisungen auf. Hier kann es ein Workaround sein, das Ausführungsdatum zu entfernen, um die Überweisung durchführen zu können.
Parallel sind wir natürlich auch dabei, die Ursachen des Fehlers zu ergründen und diesen zeitnah zu beheben.
Mit freundlichem Gruß
Gerlinde Hübl
Service DATEV Unternehmen online
DATEV eG
Hallo Frau Hübl,
die Überweisungen sind in der Tat terminiert ... und sollen es auch sein.
Weiter haben wir das Problem, dass vom Mandanten ausgeführte Sammler ab dem 15.08.2019 nicht mehr aus DUO als DTAUS-Datei exportiert werden können. Gibt es da auch eine Lösung?
Ich werde wie von Frau Brandenburg vorgeschlagen den Programmservice in Anspruch nehmen.
Weitere Tests in der Zwischenzeit haben bei uns ein völlig uneinheitliches Bild gegeben:
Einzelüberweisungen gehen inzwischen durch, aber leider NICHT alle. Ob terminiert oder nicht, spielt dabei keine Rolle.
Insbesondere institutsinterne Überweisungen (Sparkasse Mittelholstein AG) produzieren Fehler. Andere Einzelüberweisungen scheinen zu gehen. "Scheinen" deshalb, weil wir nicht alle Banken als Ziel testen können
Sammel-Ü: Gehen grundsätzlich nicht, ebenfalls unabhängig davon ob terminiert oder nicht. Auch nicht an fremde Institute.
Hallo,
aktuell konnten ausgeführte Sammler tatsächlich nicht als DTAUS-Datei exportiert werden.
Voraussichtlich Anfang nächster Woche (KW35) wird dieser Fehler behoben, so dass der Export dann wieder möglich ist.
Mit freundlichen Gruß
Gerlinde Hübl
Service DATEV Unternehmen online
DATEV eG
Hallo Herr Haller,
möchte Sie nicht verunsichern, aber ich habe jetzt seit dem 13.8.2019 einen Servicekontakt offen, außer das sich dreimal jemand auf mein System geschaltet hat, um dann festzustellen, dass "dieTechnik" sich darum kümmern muss, ist nichts passiert.
Bisher war ich von den Produkten, den Hilfen und dem Support von DATEV sehr angetan, dies wandelt sich gerade sehr.
Das Monatsende naht und ich kann immer noch nicht arbeiten.
VG
Ludger Naber
Ach, das beunruhigt mich nicht. Ehrlich gesagt habe ich Reibereien im Zusammenhang mit dieser Umstellung erwartet. Aus meiner Sicht ein völlig unsinniges Projekt (da kann aber Datev nix für), für "mehr Sicherheit". Aber ich werde hier keine Grundsatzdiskussion anfangen.
Ein bisschen ärgert mich allerdings, dass Datev erst zu Mitte August die Umstellung ermöglicht hat und dann auch gleich so, dass es kein Zurück gibt. Unsere Buchhaltung hat am WE die Gehälter inkl. allem Drum und Dran (Direktversicherung etc.) händisch online überwiesen. Ich hätte es "netter" gefunden, wenn wir das neue Verfahren parallel zum alten hätten testen und bei Bedarf das alte Verfahren weiter nutzen können. So war es ein Haufen Arbeit für nix. Und das kreide ich schon Datev an, denn es ist ja nicht so, dass die PSD2-Richtlinie erst seit gestern bekannt war. Allerdings muss man auch zugute halten, dass es hier mit vielen Beteiligten auch viele Quellen für Probleme gibt. Ich hatte beruflich mit Banken-IT zu tun, daher habe ich ein ziemlich realistisches Bild von der Sache.
Ach so: Auf meine Service-Anfrage hat sich noch keiner gemeldet. Naja, war ja auch ein Wochenende dazwischen, will mal nicht kleinlich sein.
vg heiko haller
Hallo Herr Haller,
Auch die DATEV ist mit ihrem Kooperationspartner/Drittanbieter finAPI auf die Qualität der Schnittstellen angewiesen. Da hier weitere Anpassungen notwendig waren und Voraussetzungen für die Nutzung der Schnittstellen geschaffen werden mussten, mussten wir die Freigabe generell etwas nach hinten verschieben.
Der uns verbleibende Freigabezeitraum des neuen PIN/TAN-Verfahrens ist aufgrund der Entwicklungskomplexität mit rund vier Wochen äußerst knapp. Dennoch sind wir gesetzlich verpflichtet, bis 14. September PSD2-konform zu sein und alle heutigen HBCI-Benutzer deaktiviert zu haben.
Durch die Entzerrung der Freigabezeitpunkte stellen wir sicher, dass wir Ihnen im Fehlerfall auch service- und entwicklungsseitig helfen können. Daher haben wir uns für eine stufenweise Freigabe des neuen PIN/TAN-Verfahrens (Drittanbieter-Schnittstelle) in Bank online entschieden. Dabei werden seit dem 13. August stufenweise alle HBCI-Benutzer im Programm auf „nicht initialisiert“ gesetzt. Spätestens dann müssen Sie auf ein alternatives Verfahren umstellen, damit Sie Zahlungen ausführen und Kontoumsätze abholen können.
Sie können wie bislang schon auf EBICS, RZ-Bankinfo oder Sammelverfahren mit Begleitzettel/Freigabe im Online-Portal oder mit der stufenweisen Freigabe auch auf das neue PIN/TAN-Verfahren (Drittanbieter-Schnittstelle) umsteigen.
Bei der Terminplanung der stufenweisen Freigabezeitpunkte haben wir für Sie wichtige Termine (UStVA, Sozialabgaben und Lohn) berücksichtigt und bitten Sie um Verständnis dafür, dass wir Ihnen im Vorfeld keinen genauen Zeitpunkt benennen können, an dem ein bestimmter Bank online Bestand freigeschaltet wird.
Auch den Startzeitpunkt der ersten Freischaltung der neuen PSD2-Lösung konnten wir leider nicht früher benennen, da dieser bis zuletzt unter Vorbehalt stand.
Aus diesem Grund konnten wir Sie bis dato immer nur auf den Abschluss der notwendigen organisatorischen Vorarbeiten bis Mitte August hinweisen. Eine genauere Information war unter den gegebenen Umständen nicht möglich bzw. wäre schlicht unseriös gewesen.
Aktuell arbeiten nicht nur unsere Service-Teams unter Hochdruck an der Beantwortung der eingehenden Telefonate und Service-Kontakte. Wir geben, wie immer unser Bestes, um Ihnen schnellstmöglich eine korrekte und voll umfängliche Antwort/Hilfe zu geben. Bitte haben Sie Verständnis, das auf Grund der aktuellen Situation einige Anfragen mehr Beantwortungszeit in Anspruch nehmen.
Vielen Dank.
Mit freundlichen Grüßen
Michelle Eichner
Produktmanagement Zahlungsprozesse
Guten Morgen,
schön geschrieben, nur hilft es wenig:
> Der uns verbleibende Freigabezeitraum des neuen PIN/TAN-Verfahrens ist aufgrund der Entwicklungskomplexität mit rund vier Wochen äußerst knapp.
Ja, das ist mir alles klar. Ändert aber nichts daran, dass alle Beteiligten über 2 Jahre Zeit hatten. Eigentlich sogar noch länger.
> Dennoch sind wir gesetzlich verpflichtet, bis 14. September PSD2-konform zu sein und alle heutigen HBCI-Benutzer deaktiviert zu haben.
PSD2-Konformität schließt das bisherige HBCI mit PIN/TAN-Verfahren NICHT aus. Können Sie gerne nachlesen.
By the way: Bis zum 14.09. diese zu deaktivieren wäre ja noch OK. Tatsache ist, dass die bisherigen sofort deaktiviert werden, sobald man die Migration angestoßen hat. Jetzt haben wir den Salat. Ich schrieb ja, dass es nett gewesen wäre, zumindest bis dahin auch das bisherige Verfahren auch NACH der Migration noch als "Backup" zuzulassen, um eben solche (erwartbaren) Hakeleien für die Endnutzer handhabbar zu machen. Es sind ja nur die Mitarbeitergehälter oder die Lieferanten, die ihr Geld nicht rechtzeitig bekommen (oder wie in unserem Fall die Buchhaltung, die Schichten am Wochenende schiebt, und die Überweisungen manuell ausführt, damit alle ihr Geld bekommen).
> Durch die Entzerrung der Freigabezeitpunkte stellen wir sicher, dass wir Ihnen im Fehlerfall auch service- und entwicklungsseitig helfen können.
Ist aber nicht passiert, bisher. Und Gehälter sind JETZT zu zahlen.
> Daher haben wir uns für eine stufenweise Freigabe des neuen PIN/TAN-Verfahrens (Drittanbieter-Schnittstelle) in Bank online entschieden. Dabei werden seit dem 13. August stufenweise alle HBCI-Benutzer im Programm auf „nicht initialisiert“ gesetzt.
Ich weiß nicht, was Sie unter "stufenweise" verstehen. Bei uns wurden ALLE Nutzer deaktiviert, nachdem die Migration angestoßen wurde. Dadurch konnten wir nur dumm aus der Wäsche gucken, als es Probleme gab.
> Spätestens dann müssen Sie auf ein alternatives Verfahren umstellen, damit Sie Zahlungen ausführen und Kontoumsätze abholen können.
Haben wir gemacht (16.08.) und bis heute Probleme. Und nun?
> Sie können wie bislang schon auf EBICS, RZ-Bankinfo oder Sammelverfahren mit Begleitzettel/Freigabe im Online-Portal oder mit der stufenweisen Freigabe auch auf das neue PIN/TAN-Verfahren (Drittanbieter-Schnittstelle) umsteigen.
Wir nutzen übrigens nicht Bank online, sondern RZ-Bankinfo bzw. die Datev-Anwendung "Zahlungsverkehr". Und nun?
> Bei der Terminplanung der stufenweisen Freigabezeitpunkte haben wir für Sie wichtige Termine (UStVA, Sozialabgaben und Lohn) berücksichtigt und bitten Sie um Verständnis dafür, dass wir Ihnen im Vorfeld keinen genauen Zeitpunkt benennen können, an dem ein bestimmter Bank online Bestand freigeschaltet wird.
Wie gesagt, wir nutzen nicht Bank online.
Zum Schluss: Ich behaupte ja nicht, dass Datev für die Fehlermeldungen und letztlich das Nichtfunktionieren verantwortlich ist. Da habe ich von Anfang an vermute (und in meinem ersten Post auch geschrieben), dass es Sand im Getriebe zwischen finAPI und den Rechenzentren EINZELNER Banken gibt.
Aber: Ich stelle fest, dass es ziemlich cool gewesen wäre, wenn die alten Nutzer nicht einfach deaktiviert werden, wenn man die Migration anstößt. Das ist tatsächlich eine Datev-Baustelle und aus meiner Sicht völlig unnötig gewesen. Denn solche Nutzer bestehen zu lassen und am 14.09. zwangsweise zu deaktivieren, wäre sicherlich möglich gewesen. Damit hätten wir ein Backup für die Durchführung der Zahlungen gehabt und gleichzeitig die Möglichkeit, mit den neuen Nutzern die Fehler zu lokalisieren und weiter zu probieren, bis es geht.
Entschuldigen Sie bitte meinen harschen Ton, aber mich nervt es gewaltig, dass solche Sachen a) nicht funktionieren und b) der Weg "zurück" gewaltsam und vorzeitig abgeschnitten wurde. Mir tun die Menschen leid, die jetzt hektisch und meist auch mit Sonderschichten den Zahlungsfluss in den Unternehmen (und Kanzleien) sicher stellen müssen. Das war unnötig und ich ärgere mich sehr darüber, dass dann nur beruhigende Texte veröffentlicht werden, die suggerieren, dass alles toll ist und man ja an alles gedacht habe. Ist es nicht und hat man nicht.
Viele Grüße und auf dass wir das hier baldmöglichst vergessen können.
Heiko Haller
Sehr geehrte Frau Eichner,
seit letzter Woche sind wir auch von der Umstellung "betroffen". Der Selbstversuch mit dem eigenen HBCI-Zugang hat dabei noch wunderbar funktioniert.
Seit vergangenem Freitag verbringe ich täglich ca. 2 Stunden meiner Arbeitszeit um gemeinsam mit Mandanten fehlgeschlagene Umstellungen zu analysieren und jeweils der Datev mitzuteilen. Gelöst ist bislang keiner dieser Fälle. Die Fehler werden jeweils nur mit "Hochdruck" analysiert.
Dafür, dass hier mit der Hozlhammermethode der bestehende Zugang deaktiviert wird und der neue Zugang eingerichtet werden muss, ist diese Fehlerquote schlicht eine Zumutung. Die Fehlercodes von finAPI sind ebenfalls maximal nichtssagend.
Sie greifen hier in Prozesse der Mandanten ein, die täglich und zeitnah benötigt werden. Insbesondere bei Skonto-Fälligkeiten oder fälligen Rechnungen oder Lohnzahlungen ist das nicht akzeptabel.
Mit freundlichen Grüßen
Stefan Kolb
Hallo Herr Haller,
ich versuche auf all Ihre Punkte zu antworten.
Ja, das ist mir alles klar. Ändert aber nichts daran, dass alle Beteiligten über 2 Jahre Zeit hatten. Eigentlich sogar noch länger.
-> Das Gesetzt ist am 13.01.2018 in Kraft getreten, das ist richtig. Es herrscht sehr viel Bewegung im Markt, sowohl bei der Umsetzung der Datenschnittstellen bei den einzelnen Banken als auch bei den Regularien der BaFin (Bundesaufsicht Finanzen). So konnten erste Tests der bankenindividuellen Schnittstellen zwischen Drittanbieter und Banken erst im Juli statt im März dieses Jahres durchgeführt werden. Der nachfolgende Artikel gibt die Situation im Markt aus meiner Sicht sehr gut wider: https://www.handelsblatt.com/finanzen/geldpolitik/kontozugriff-unmut-ueber-neue-konto-schnittstellen/24515602.html
PSD2-Konformität schließt das bisherige HBCI mit PIN/TAN-Verfahren NICHT aus. Können Sie gerne nachlesen.
By the way: Bis zum 14.09. diese zu deaktivieren wäre ja noch OK. Tatsache ist, dass die bisherigen sofort deaktiviert werden, sobald man die Migration angestoßen hat. Jetzt haben wir den Salat. Ich schrieb ja, dass es nett gewesen wäre, zumindest bis dahin auch das bisherige Verfahren auch NACH der Migration noch als "Backup" zuzulassen, um eben solche (erwartbaren) Hakeleien für die Endnutzer handhabbar zu machen. Es sind ja nur die Mitarbeitergehälter oder die Lieferanten, die ihr Geld nicht rechtzeitig bekommen (oder wie in unserem Fall die Buchhaltung, die Schichten am Wochenende schiebt, und die Überweisungen manuell ausführt, damit alle ihr Geld bekommen).
-> Wenn Sie beispielsweise über ein Bankprogramm das HBCI PIN/TAN Verfahren nutzen, können Sie das auch weiterhin wie bisher nutzen.
Bei DATEV werden die Zahlungen über das DATEV Rechenzentrum gesendet. Deswegen ist DATEV vom ZAG betroffen. Aus diesem Grund müssen bis 14.09. alle heutigen HBCI-Benutzer deaktiviert sein. Die offiziell kommunizierten Umstellungstermine (Zahlungsverkehr und Bank online) sind z.B. auf unserer Landingpage aufgeführt:
-> Bei der Migration des ersten HBCI Benutzers auf finAPI kommt eine Hinweismeldung mit ACHTUNG - WICHTIG – UNBEDINGT LESEN, in der darauf hingewiesen wird, dass nach der ersten Umstellung alle weiteren HBCI Benutzer im Datenbestand auf „nicht initialisiert“ gesetzt werden. Dies ist auch im Info-Dokument 1004176 (DATEV Zahlungsverkehr – Umstellung auf den Drittanbieter finAPI GmbH, Schritt-für-Schritt-Anleitung) so aufgeführt.
Ist aber nicht passiert, bisher. Und Gehälter sind JETZT zu zahlen.
-> Wenn ich es richtig verstanden habe, nutzen Sie DATEV Zahlungsverkehr. Hier kann frei ein Umstiegszeitpunkt vom 09. August bis 09. September 2019 von Ihnen bestimmt werden.
Ich weiß nicht, was Sie unter "stufenweise" verstehen. Bei uns wurden ALLE Nutzer deaktiviert, nachdem die Migration angestoßen wurde. Dadurch konnten wir nur dumm aus der Wäsche gucken, als es Probleme gab.
-> Die stufenweise Freigabe gilt nur für Bank online. Bzgl. der Deaktivierung aller Nutzer, habe ich Ihnen im Punkt oben bereits geantwortet.
Haben wir gemacht (16.08.) und bis heute Probleme. Und nun?
-> Welche konkrete Fehlermeldungen erhalten Sie derzeit? Was funktioniert nicht? Wenn Sie dazu bereits einen Servicekontakt geschickt haben, können Sie sicher sein, dass wir so schnell wie nur möglich versuchen zu antworten.
Die Herausforderungen der PSD2, mit denen auch Sie aktuell zu kämpfen haben, sind für alle Beteiligten ein Kraftakt. Der gesamte Markt ist davon betroffen.
Wir versuchen, Sie so gut es geht mit Informationen unter www.datev.de/zag, hier in der Community und zu guter Letzt auch im Service bei der Umstellung zu unterstützen.
Gerne stehe ich auch für ein persönliches Gespräch zur Verfügung. Rufen Sie bei Bedarf gerne unter der Programm-Hotline mit der Nummer 0911 319 36630 an und verlangen nach mir.
Mit freundlichen Grüßen aus Nürnberg
Michelle Eichner
Produktmanagement Zahlungsprozesse