angeblich fehlende notwendige Berechtigung zum Zugriff auf Digitale Belege aus Meine Steuern

[#1]

Hallo Community, 

wir erhalten die Fehlermeldung "Sie verfügen nicht über die notwendige Berechtigung zum Zugriff auf Digitale Belege aus Meine Steuern". 

Vorab: 

• Die  Voraussetzungen aus Der Weg zum digitalen Belegaustausch in DATEV Meine Steuern sind erfüllt
• Die Kanzlei-Mitarbeiter sind mit dem RZ verknüpft 
• Die Rechte der Kanzlei-Mitarbeiter bzw. deren Zugangsmedien sind für die Mandanten freigeschaltet
• Die Mandanten sind in MyDatev registriert (und werden auch als registrierte in der Kanzleisoftware) angezeigt 
• Die Punkte aus dem Thread DATEV Meine Steuern - Zugriff als Mitarbeiter beim Mandanten sind erfüllt [wobei wir nicht den Umweg gehen wollen die Daten erst herunterzuladen, um sie dann wieder einzuspielen]

Spannend ist die Tatsache, dass wir über "Meine Steuern - Kanzleisicht öffnen" die Daten einsehen (sogar bearbeiten) könnten. 

Nur im Programm Einkommensteuer kommen die Belege nicht an und können somit nicht weiterverarbeitet werden.

Die exakte Fehlermeldung lautet:

1) Sie verfügen nicht über die notwendige Berechtigung zum Zugriff auf Digitale Belege aus Meine Steuern. 

>>Bitte überprüfen Sie das verwendete Authentifizierungsmedium (z.B. DATEV Smartcard) auf vorhandene Berechtigungen. Wenden Sie sich ...

2) #RZK77022: 

Fehler beim Verbinungsaufbau zu https://srv1:XXXXX  der Remoteserver hat Fehler zurückgegeben (403) Unzulässig. 

Kennt jemand das Problem? 

(Nutzung PartnerASP - Lösung über WTS) 

Danke im Voraus, 

Oli Nachtrab 

[#2]

---

@olinamd  schrieb:

2) #RZK77022: 

Fehler beim Verbinungsaufbau zu https://srv1:XXXXX  der Remoteserver hat Fehler zurückgegeben (403) Unzulässig. 

---

Bitte einmal einen RZ Kommunikationstest machen und auf SOAP und REST achten. Läuft da alles durch? Fehlerfrei? Oder kommt hier der gleiche Fehler? Der RDS kann wohl keine https-Verbindung zum DATEV Fileserver / Kommunikationsserver SRV1 aufbauen.

Dann wird nicht die eigene SmartCard als Authentifizierung genutzt, sondern der Kommunikationsserver, der wiederum den DATEV Benutzer im RZ anspricht. Aber die Kommunikation zwischen RDS und DATEV Kommunikationsserver scheint gestört zu sein. 

DATEV Benutzerverwaltung ist alles OK: der Benutzer ist grün und hat neben dem Windows Benutzer auch einen verknüpften DATEV Benutzer? 

[#3]

@metalposaunist : Danke für die nützlichen Tipps. Ich habe das in an den ASP Provider weitergeleitet. Sobald ich Feedback habe, melde ich mich. 

Benutzerverwaltung: Benutzer ist grün (im einen Fall sogar die Kanzleiinhaberin), gleiche Nutzer haben Windows Benutzer, DATEV-Benutzer und sind im RZ bekannt. 

Eine Befürchtung habe ich noch, die ich testen werden:

1) ehemals wurden die genutzten lokal gesteckten SmartCards(hier mIDentity Sticks) in einem Fall mit einer anderen (der zentralen Email adresse der Kanzlei) E-Mail angelegt. Somit hat der DATEV Benutzer innerhalb der Kanzlei-SW andere E-Mail, als der genutzte Stick. Stick ist dennoch identifiziert. 

2) Im anderen Fall ist der genutzte Stick nicht korrekt / gar nicht identifiziert, funktioniert aber mit anderen Abrufen einwandfrei. 

[#4]

Zu 1: E-Mail-Adressen auf den SmartCards haben wenn dann nur bei einer S/MIME E-Mail Verschlüsselung damit zu tun. 

Zu 2: nicht korrekt / gar nicht identifiziert heißt was? Steuerkonto Online hat damit auch nichts zu tun. 

[#5]

Hallo,

Zu 2: nicht korrekt / gar nicht identifiziert heißt was? Steuerkonto Online hat damit auch nichts zu tun. 

=> damit meinte ich, dass einer der Sticks zwar zur Identifizierung an DATEV gesendet wurde, aber die DATEV-Zertifikatsabfrage keine Resultate liefert. 

Die Prüfungen bzgl. SOAP und Rest führen mich näher an die Lösung. SOAP Services liefen fehlerfrei (unter Nutzung gesteckter SmartCard), REST-Services bringen Fehler. Im Funktionstest (innerhalb des DATEV Arbeitsplatzes) steht noch der DATEV Hinweis: .. Das Ergebnis hat keine Relevanz für die Verarbeitung der DFÜ-Aufträge durch die RZ-Kommunikation. Für neue Anwendungen, die eine RZ-Webservicekommunikation im Rechenzentrum ansprechen, ist ein positives Ergebnis jedoch erforderlich." => REST-TEST nicht erfolgreich. 

Offensichtlich nutzt Digitale Belege Steuern Webservices zum Abruf innerhalb des Programmes Einkommensteuer.

[Unternehmen Online - Belegübernahme (Buchführung) offensichtlich nicht,  denn diese kommen an.]

Nach Hotlineanruf habe ich folgendes Dokument geprüft: #RZK77022 

In unserer Kanzlei liegt bei keinem Webservicekommunikation.xml im Standard Daten-Pfad  (z.B. L:\DATEV\DATEN\RZKOMM\DATA\STANDARD).

Ich gebe Update, sobald Info von unserem ASP Provider kommt. 

[#6]

Hallo olinamed,

wie ich gestern erfahren habe ist, das unter der Beraternummer des miDentitys (Smartcard) auch bei Datev ein Steuerprogramm im Vertrag vorhanden sein muss. Bei mehreren Hauptberaternummern, wo die Software unter einer bestimmten Hauptberaternummer installiert wird, muss das Logistikcenter erst die anderen Hauptberaternummern (Mitgliedschaften) für meine Steuern freischalten. Liegt der Fall bei Ihnen evtl. vor?

M. Hölbe

[#7]

Lösung gefunden: 

In den Proxyeinstellungen der Internetoptionen die Ausnahme (also "für Adressen, die wie folgt beginnen, keinen Proxyserver verwenden") müssen die Server hinzufügt werden, (in unserem Fall) die Einträge srv1 und srv1.dom.local 

Danach liefert der Funktionstest keine Fehlermeldung mehr.

Der Import der Belege im Programm Einkommensteuer über den Button "Digitale Belege" läuft nun auch fehlerfrei! 

Die "fehlende" Webservicekommunikation.xml - Datei war/ist nicht die Ursache. 

[#8]

Top. Habe ich ja gesagt, dass der TS nicht den FS SRV1 erreicht, weil der TS über den Proxy geht und da natürlich keinen SRV1 gibt, weil der ja lokal "neben" steht 😉. 

[#9]

Danke @m_hoelbe ,

das war bei uns nicht die Problematik, da (wie im ersten/initialen) Kommentar vermerkt, die Voraussetzungen erfüllt sind, d.h. notwendige Programme sind installiert und "bei DATEV bekannt", für alle BNR der Kanzlei. "Meine Steuern" für Kunden registriert, etc., Rechtevergabe war auch nicht die Problematik.

Ausschließlich die Kommunikation zwischen RDS und den Servern war das Problem.

Hinweis: ASP Provider hatte Serverseitig andere Einstellungen, daher trat dort das Problem nicht auf (aka: Kommunikation hat funktioniert und auch die entsprechenden Tests), aber auf den Clients fehlten die Proxy-Einstellungen, so dass Server und Clients sich unterschiedlich verhielten. 

Vielen Dank trotzdem für den Hinweis! 

Oli Nachtrab