Informationen zu _lars_ - DATEV-Community

_lars_ · ‎22.08.2025

Wie meinst du das? Die Lohnabrechnung soll doch nicht ausgelagert werden. Oder missverstehe ich da etwas?

_lars_ · ‎22.08.2025

Läßt sich die Version 15.1 auch unter Datev 18 installieren (und funktioniert dann auch)?

_lars_ · ‎22.08.2025

Fehlermeldung im Assistent Mandantendatenübertrag: Fehler #LN27133 Die Sicherung wurde mit Lohn unf Gehalt Version 15.1 erstellt. Installieren Sie diese oder eine höhere Version, um den Datenbestand einspielen zu können. Der Assistent wird nun geschlossen. Das Zielsystem kann noch nicht auf Datev 19.0 aktualisiert, die Lohndaten müssen aber dringend importiert werden. Gibt's irgendeine Möglichkeit, die Daten in das "alte" Datev eingespielt zu bekommen? Danke Lars

_lars_ · ‎24.06.2025

Sorry, wenn ich naiv nachfrage, ich verstehe die Logik noch nicht richtig. Würdest Du mir liebenswürdiger Weise die "Freigabelogik" anhand meines Beispiels erklären? Irgendwie empfinde ich meine Herangehensweise logisch: 1) alle Nutzer sollen auf alles zugreifen können -> "Alle Freigaben" 2) ein Mandanten soll gesperrt bleiben -> eine Gruppe mit dieser Sperre über die Globalrechte 3) Ausnahme für bestimmte Programme innerhalb dieses Mandanten -> weitere Gruppe mit Globalsperre aber Freigabe einzelner Programme Empfinde ich als logisch und vor allem zukünftig les- und nachvollziehbar.

_lars_ · ‎24.06.2025

Ich bin noch relativ unbewandert das lokale Berechtigungskonzept betreffend. Folgendes möchte ich erreichen: Für die Nutzer hier gibt es nur eine Gruppe "Sperre X", in der ein bestimmter Mandant gesperrt ist. Die Sperre ist über "PC-Anwendungen -> Globalrechte -> Berater/Mandant -> Beraternummer/Mandantennummer" gesetzt. Alle Nutzer bekommen die Gruppen "Alle Freigaben" und "Sperre X" zugeordnet. Funktioniert so, wie es soll. Jetzt möchte ich aber bestimmten Nutzern für diesen Mandanten bestimmte Programme freigeben, z.B. "FiBu" soll freigegeben werden, aber "Lohn" gesperrt bleiben. Also hab ich blauäugig meine Gruppe "Sperre X" kopiert, sie "Sperre X mit Ausnahme FiBu" genannt und in dieser neuen Gruppe unter "Programme" den Unterpunkt "Rechnungswesensysteme" mit Rechtsklick rekursiv freigegeben. Danach steht ein grünes Häkchen vor "Rechnungswesensysteme". Aber es funktioniert nicht. Ist das von der Logik her richtig oder begehe ich einen Denkfehler?

_lars_ · ‎25.07.2024

@rschoepe schrieb: Was mir da gerade noch aufgefallen ist: wieso hatte das Zertifikat eine Gültigkeitsdauer von 1 Jahr und 27 Tage? Das ist ja mal ein extrem krummer Wert. Weil es für den Austausch logischer Weise etwas Puffer (Überlappungszeitraum) benötigt. Meist ca 30 Tage, d.h., das neue Zertifikat ist ca. 30 Tage vor dem Ablaufdatum des alten gültig.

_lars_ · ‎25.07.2024

@chrisocki schrieb: Cache-Fehler? Bei mir sind keine Auffälligkeiten. HTTPS kann prinzipbedingt nicht gecached werden.

_lars_ · ‎25.07.2024

Bei meinen Kunden auch. Der "COMMON_NAME_INVALID" deutet darauf hin, daß im Zertifikat der FQDN "login.datev.de" fehlt(e). Hier geht's jetzt wieder.

_lars_ · ‎01.10.2023

@metalposaunist schrieb: Windows Kommandozeile öffnen (Windowstaste+R > cmd): ping komm-srv-1 eintippen > Enter; antwortet da was unter < 1ms ist er zu 99% installiert. Der Tipp ist mMn kein wirkliches Indiz für die Existenz des Kommunikationsservers, da viele Dienstleister den A-Record für "komm-srv-1" im DNS-Server anlegen, weil sie der Meinung sind, daß es eine gute Idee bzw. nicht falsch ist ("Das hab ich immer schon so gemacht"). Wie bekommt man denn zuverlässig (und ich meine wirklich zuverlässig) heraus, ob der Kommunikationsserver installiert ist bzw. war, wenn eine Update-Installation an einem Punkt abgebrochen ist, an dem der Installationsmanager nicht mehr funktioniert?

_lars_ · ‎08.09.2023

Hat hier jemand eine OnPremise-Umgebung mit 2016er Servern (Fileserver und RDS) und Office 2019 problemlos am laufen?

_lars_ · ‎13.09.2022

@ALL: Sorry, vermutlich war meine Frage nicht präzise genug formuliert. Wieviele Netzteile Server haben sollten, wie/wo man beide Netzteile anschließt, wieviel Batterielaufzeit kalkuliert werden sollte, wie man VMs (automatisiert) steuert usw., das ist alles klar, umgesetzt und nicht Grund meiner Frage. Mir geht es rein darum, wie ich die DATEV-VMs (also DATEV selbst) im dem Falle behandeln kann/muß, wenn die USV signalisiert, daß sie die definierte Batterierestlaufzeit erreicht hat. Kann ich die beiden VMs (VM1=File-/Datenbank-Server, VM2=WTS) einfrieren (wobei ich mir schon denken konnte, daß das wohl mit DATEV nicht funktioniert) oder einen Shutdown durchführen? In welcher Reihenfolge fahre ich die VMs herunter (mich interessiert dann auch das warum)? Was ist noch zu bedenken? Das müßt ihr, dir ihr mir hier die Tipps gebt, bestimmt auch schon mal durchdacht, umgesetzt und damit Erfahrungen gemacht haben!? Gibt's dazu offzielle Dokumente von DATEV? Lars

_lars_ · ‎13.09.2022

Für eine Umgebung, in der DATEV als Terminalserver-Lösung läuft, hätte ich gern gewußt, was die empfohlene Vorgehensweise ist, wenn die USV niedrige Batteriekapazität meldet. Können die VMs bedenklos eingfroren werden, so daß die Mitarbeiter später "nahtlos" weiterarbeiten können oder fährt man die VMs ohne Rücksicht auf die nicht gespeichert Arbeit der Nutzer herunter?

_lars_ · ‎13.01.2022

@vogtsburger: Im Installationsmanager ist weder "Kanzlei-Rechnungswesen" noch "DATEV Mittelstand Faktura mit Rechnungswesen (Compact)" installiert. Dennoch stellt sich mir die Frage, warum die Vorversion 2.8 installiert ist, das Update auf 2.9 aber an einer Abhängigkeit scheitert? Solche grundlegenden Änderungen macht man doch nicht in einem Service-Release!

_lars_ · ‎13.01.2022

Mal versuchsweise dies oder jenes neu zu installieren, ist eine Vorgehensweise, die ich nur ungern durchführe, weil a) eine Löung ungewiss ist und b) meist neue Probleme auftreten. Falls niemand eine Lösung kennen sollte, werde ich erstmal abwarten, ob bzw. bis jemand dieses Modul nutzen will. Andern falls warte ich bis zum nächsten Service-Release in der Hoffnung, daß sich das Problem damit "von selbst" löst. 😉

_lars_ · ‎13.01.2022

gerade beim Update auf (V.15.0) Service-Release 31.12.2021: DÜ Formulare Rechnungswesen V.2.9 #INI07230 Die Installationsvoraussetzung ist für das Programm DÜ Formulare Rechnungswesen V.2.9.8 (T0000174) nicht erfüllt. Grund: Für die Installation von DÜ Formulare Rechnungswesen muss ein Rechnungswesen installiert sein. Der Installationsmanager sagt: Produkt: DÜ Formulare Rechnungswesen V.2.9.8 Enthalten in Auslieferung: - Service-Releases (30.12.2021) zu DATEV-Programme V.15.0 Installationsinformationen: Arbeitsplatz - Es ist die ältere Version V.2.8.93 installiert Was ist mit "ein Rechnungswesen" gemeint? Rechnungswesen ist installiert. Ich glaube nicht, daß sich Abhängigkeiten in einem Service-Release so grundlegend ändern.

_lars_ · ‎12.01.2022

Beheben konnte ich das durch die Neuinstallation der VIWAS Managementconsole, wie in 1018332 beschrieben.

_lars_ · ‎11.12.2021

Mein Setup besteht aus zwei Servern: 1) File- und Datenbank-Server 2) Terminal-Server Das Update lief problemlos durch, lediglich beim Status des Terminal-Server stand ein Ausrufezeichen mit dem Hiweis auf Warnungen. "Es wurden keine Datenpfade mit anzupassenden Daten zugewiesen" (Folge vom Update auf v15?). Also Datenanpassung händisch gestartet, Server neu anghakt und bei der Datenanpassung VIWAS Managementconsole: [11.12.2021 21:17:48.446]........[21:17:48]........................*error* MsSqlBatch Fehler: Ausnahme in ExecuteConnBatch(). Fehlerwert 526: Fehlertext: Bei der Verarbeitung eines Skripts ist ein Fehler aufgetreten. *error* Cannot find the object "DATEV.u_vim_GroupsPolicies" because it does not exist or you do not have permissions. Skript: D:\DATEV\KONFIG\B0000402\Trafo\v.3.0\VIM_Con-ve.sql Stapel: 39/80 Zeile: 683 [11.12.2021 21:17:48.446]........[21:17:48]......................END (Dauer:2 sec) mssqlbatch RC: 0x80004005 [11.12.2021 21:17:48.446]........[21:17:48]....................END (Dauer:2 sec) step VAdmin database migration to v.3.0 RC: 0x80004005 [11.12.2021 21:17:48.446]........[21:17:48]..................END (Dauer:2 sec) steps RC: 0x80004005 [11.12.2021 21:17:48.446]........[21:17:48]................END (Dauer:2 sec) if RC: 0x80004005 [11.12.2021 21:17:48.446]........[21:17:48]..............END (Dauer:2 sec) execution, RC: 0x80004005 [11.12.2021 21:17:48.446]........[21:17:48]............END (Dauer:3 sec) include RC: 0x80004005 [11.12.2021 21:17:48.446]........[21:17:48]..........END (Dauer:9 sec) step Update DATEV database infrastucture RC: 0x80004005 [11.12.2021 21:17:48.446]........[21:17:48]........END (Dauer:9 sec) steps RC: 0x80004005 [11.12.2021 21:17:48.446]........[21:17:48]......END (Dauer:10 sec) migration VIWAS Managementkonsole database migration from |v.2.8|[11.12.2021 21:17] RC: 0x80004005 [11.12.2021 21:17:48.446]........[21:17:48]....END (Dauer:10 sec) migrations RC: 0x80004005 [11.12.2021 21:17:48.446]........[21:17:48]..END (Dauer:10 sec) execution, RC: 0x80004005 [11.12.2021 21:17:48.446]........Error info hresult = 0 [11.12.2021 21:17:48.446]........Execution module hresult = -2147467259 [11.12.2021 21:17:48.446]........Legacy data path state: state_incomplete_error [11.12.2021 21:17:48.446]........DataPathState = Incomplete [11.12.2021 21:17:48.446]......END DataAdaptation.ExecutePath [11.12.2021 21:17:48.446] [11.12.2021 21:17:48.446]....END Action [11.12.2021 21:17:48.446] [11.12.2021 21:17:48.446]..END Actions [11.12.2021 21:17:48.446] [11.12.2021 21:17:48.446]END Sandbox-Operation Cannot find the object "DATEV.u_vim_GroupsPolicies" because it does not exist or you do not have permissions. An der Berechtigung wird's höchstwahrscheinlich nicht liegen. Was könnte das sein?

_lars_ · ‎28.07.2021

Hat in der Zwischenzeit jemand ZEN2/3-Epycs mit einem Basistakt von unter 3GHz im Einsatz und kann Erfahrungen teilen? Braucht DATEV immer noch die schiere Gigaherz-Zahl?

_lars_ · ‎21.12.2020

Der EPYC 7371 ist aber schon 2 Jahre alt! Der gehört nicht zur Ryzen 3er Serie... Ich wollte damit zum Ausdruck bringen, daß AMDs Zen(1)-Architektur schon leistungsfähig genug war/ist, nicht erst ZEN+ oder ZEN2. EDIT: Außerdem, worin liegt der Unterschied zw. Ryzen 3rd Generation und EPYC 1st Generation? Es sind beides CPUs mit Zen-Architektur. Sicher hat die Zen2-Arch. einige Detailverbesserungen erhalten, das wirkt sich aber nur marginal auf die Pro-Core-Performance aus.

_lars_ · ‎20.12.2020

Auf geht's! Wer kann hier bestätigen, dass DATEV damit rennt? Dazu eine aktuelle PCIe 4.0 x4 NVMe SSD mit bis zu 7GB/s (weil AMD PCIe 4.0 standardmäßig an Board hat und Mainboards damit ausgestattet sind) und DATEV muss rennen 😍! Hier 1x Epyc 7371 (zweiter Sockel auf Board noch frei), 128GB RAM, 2x Samsung PM1643 (3,92TB, SAS 12Gb/s) im RAID1 für DATEV mit DMS, separates SSD-Raid für Fileserver Läuft mit 2VMs (VM1 mit AD/DATEV-DB/KommSrv/FileSrv und VM2 WTS) und 15 Usern absolut problemlos und es ist noch genug Luft in Bezug auf CPU-Auslastung Virtualisierung: Linux KVM

_lars_ · ‎20.12.2020

Das ganze lief jetzt über mindestens zwei Jahre so. Wie gesagt, ich habe das Windows-Upgrade nicht gemacht, das ist schon ziemlich lange her. Das Zertifikat muß am Freitag oder gestern abgelaufen sein. Wenn ich mir das neue anschaue, ist das für Zehn Jahre ausgestellt. Das war dann wohl beim alten ähnlich... Ich hab mich jetzt mal durch die logs gewühlt und fand in dem vom DFÜ-Funktionstest das: Name des Komm.-Servers: W2012FS (aus XML-Datei ermittelt) Danach durch alle '*.xml' im DATEV-Verzeichnis nach "w2008fs" gegrept und voilà: d:\WINDVSW1\DATEV\DATEN\RZKOMM\DATA\STANDARD\WebserviceKommunikation.xml Darin den Hostnamen angepaßt (und aus Unwissenheit, ob und welche Dienste man hätte neu starten müssen, den ganzen Server rebootet) und es läuft wieder. Das es nur das Zertifikat des Kommunikationsservers betraf, erwarte ich kein weiteres Problem.

_lars_ · ‎20.12.2020

Leider hab ich das nicht gemacht, sondern die Installation nur übernommen. Ist eine normale Standard-Installation mit zwei Servern: 1) AD + DB + Komm usw. 2) WTS Vermutlich wurde die Umbennung mit dem Assistenten gemacht und der hat das vergessen? Wenn ich dem 'hostconf'-Tool einfach einen "Subject Alternative Name" für's Zertifikat mitgeben könnte, würde das mein Problem vermutlich schon lösen.

_lars_ · ‎20.12.2020

#RZK77167 Authentisierungfehler beim Verbindungsaufbau zum Kommunikationsserver https://w2008fs:58452/datev/framework/idp/onpremise/.well-known/openid-configuration: Das Remotezertifikat ist laut Validierungsverfahren ungültig. Hintergrund: der Kommunikationsserver wurde beim Upgrade auf Windows Server 2012 in "w2012fs" umbenannt. Der alte Name blieb im DNS als Alias erhalten, somit funktionierte das ganze. Jetzt lief das Zertifikat aus und wurde mit CN "w2012fs" erneuert. Damit kann aber auf den Kommunikationsserver nicht mehr mit "https://w2008fs:58452/..." zugegriffen werden. Wo konfiguriere ich den Hostnamen für den Zugriff auf den Kommunikationsserver, um dort den alten Namen "w2008fs" zu ersetzen? Danke schon mal Lars

_lars_ · ‎01.12.2020

Als ich das letzte Woche bei der Mitarbeiterin eingerichtet hatte, funktionierte es mit einer anderen SmartCard problemlos, nur mit ihrer nicht.

_lars_ · ‎30.11.2020

Eine Steuerberaterin möchte ihren Kammermitgliedsausweis auch gleich als SmartCard benutzen. Der Antrag wurde entsprechend ausgefüllt, PIN ist da und Karte aktiviert. Die Kartenprüfung meldet auch: "Die Karte kann für den Datenabruf bei der Finanzverwaltung eingesetzt werden." Benutzt sie aber die Karte für die Steuerkontenabfrage bei der Finaznverwaltung, so kommt die Meldung: DATEV SmartCard [Kartenlesertyp...] Der angeforderte Vorgang kann mit dieser SmartCard nicht ausgeführt werden, ... Vermutlich fehlt eine Berechtigung? In der Rechteverwaltung Online hat diese Mitarbeiterin zwar ihren Datev-Benutzer zugeordnet, aber keinen Kammermitgliedsausweis (SmartCard). Müßte diese SmartCard nicht dort auftauchen?

_lars_ · ‎20.11.2020

Hatte es aber bisher noch nicht als Problem angesehen, dass das Windows 10 zu alt ist. Hatte auf einem 1809 auch noch DATEV inkl. REWE und SQL 2017 installiert. Lief. Würde eher behaupten, dass "dein" Windows 10 vielleicht "kaputt" war? Bei einem Upgrade von 1903 auf 2004 wird Windows 10 ja neu installiert und das alte unter windows.old abgelegt. Gut möglich. Lokal ist das SiPa aber grün? Möglich auch hier, dass ein Upgrade die notwendigen Windows (10) Funktionen quasi repariert. Aus Erfahrung mit WTS Server 2012 R2 inkl. SiPa 6.81: lokal braucht man weder SiPa noch die SC-Treiber dazu. Klappt out-of-the-box die SmartCard Durchreichung. Lokal ist kein SiPa installiert, lediglich die DATEV-SC-Treiber. Aber gut zu wissen, daß es die auch nicht mehr braucht. Ich schaue Montag wieder nach dem Notebook und melde mich dann wieder.

_lars_ · ‎20.11.2020

Geholfen hatte ein Windows-Funktionsupdate. Das Client-System lief noch mit einer 1903 und nach Update auf 2004 klappte alles wie gewohnt. Weißt Du (oder jemand anderes), welche Funktionsversion das aktuelle SiPa voraussetzt? Ich finde diese Information in den Systemvoraussetzungen leider nicht. Bin gerade über einem ähnlichen Problem auf einem anderen Notebook, hier ist die Gegenstelle aber ein Terminalserver und das SiPa auf dem WTS bleibt von einem zum anderen Tag rot, also keine Smartcard erkannt. Der Client hat auch noch die 1903 und updatet gerade auf 2004.

_lars_ · ‎10.11.2020

Homeoffice-Szenario mit RDP nach Workstation (kein WTS!) in Kanzlei. Mit dem Update auf SiPa 6.82 klappt ja das Durchreichen eines SmartTokens vom RDP-Client zum RDP-Ziel wieder. Auch hier auf dem Notebook einer Mitarbeiterin ist das SiPa nach RDP-Anmeldung grün, ihre SmartCard wird richtig ausgelesen, der Gesamtbasistest meldet 0 Fehler. Mit aktuellen MS Chromium Edge und Firefox ESR 78.4.1 klappt aber die Anmeldung an Datev Unternehmen Online (duo.datev.de) nicht: (SmartCard-Typ: KOBIL Systems Smart Token 1) Der Login-Prozess holt sich das Zertifikat vom Token und läßt es mich bestätigen. Es kommt die PIN-Abfrage durch SiPa. Danach werkelt der Browser (egal ob MSCE oder Firefox) und meldet dann: Fehlerhafte Authentifizierung. Wenn die Kollegin aber direkt an ihrem PC im Büro sitzt, klappt der Zugriff problemlos. Es muß also irgendetwas mit SiPa/RDP zu tun haben. Hat jemad eine Idee? Danke Lars

_lars_ · ‎09.12.2019

Wenn das "nur" eine Meldung beim Neustart ist, die sich später von selbst behebt, wäre halt eine Meldung im Ereignis-Log nett, daß die Konsistenz wiederhergestellt ist, damit man nicht nach etwas sucht, was nicht da ist. 😉

_lars_ · ‎07.12.2019

Ampel ist grün, RZ-Test läuft ohne Probleme durch.

Beiträge und Ideen von _lars_

Auszeichnungen