Hat jemand bereits Erfahrungen mit der Erfassung von neuen Mitarbeitern, wenn diese über einen ASCII-Import erfolgt (alle neuen Mitarbeiterdaten werden auf einmal hochgeladen, aufgrund dieses neuen Aspekts, einschließlich aller relevanten Felder für die Vnr.Abfrage)?   Da es kein separates hochladbares Feld (Schnittstellenhandbuch) für die „Versicherungsnummernabfrage“ gibt(?), stellt sich die Frage, ob diese automatisch ausgelöst wird oder nicht, auch wenn der neue Mitarbeiter nicht manuell über die Option „Mitarbeiter Neu“ hinzugefügt (+ automatisch das Haken bei "Vnr.Abfrage") wurde? Wie empfohlen, nach dem ASCII-Import haben wir alle Daten über die Funktion „Stammdaten komplett“ ins RZ eingesendet.   Dies hängt natürlich auch mit der Frage / Möglichkeit zusammen, ob diese neue Vorgehensweise tatsächlich verpflichtend ist oder nicht (Thema Pflichtenheft 2024.2, relevant nur für Versorgungsbez.empf. oder auch für aktive MAn, etc.) = wenn die RV-Nummer vorhanden ist, kann man sie einfach eingeben, so wie man es bisher gemacht hat (in unserem Fall durch den ASCII-Import).   Vielen Dank im Voraus! ... Mehr anzeigen

Hallo Zusammen,   ich möchte noch einmal auf dieses Thema zurückkommen: gibt es vielleicht einen Plan, die derzeitige Bearbeitungsmethode zu überarbeiten? Wie ursprünglich von lohnexperte beschrieben, hatte auch ich schon mehrfach das Problem, dass nach einer ÜG-Periode keine KG EEL erstellt wurde. Die Praxis zeigt, dass die DRV in solchen Fällen ganz selten oder eher nie die Entgeltdaten an die KKs übermittelt (andersherum funktioniert die Datenübermittlung viel besser!).   Ich verstehe alle hier von DATEV zuvor aufgeführten Gegenargumente, aber wäre es vielleicht möglich, die Übermittlung der EEL für die Einzelfälle 'KG-Periode folgt auf eine ÜG-Periode' zu ermöglichen? Es scheint, dass in diesen Fällen die elektronische Kommunikation zwischen DRV und der jeweiligen KK deutlich weniger reibungslos funktioniert als umgekehrt (Erfahrung zeigt dass im umgekehrten Szenario übermittelt die KK die Lohndaten an die DRV! = die Einschränkung gleichbleibende Bemessungsgrundlage' führt in diesen Fällen nicht zu weiteren Problemen). Vielen Dank im Voraus! MfG ... Mehr anzeigen

Sehr geehrte Frau Simmerlein,   ich kann auch bestätigen, dass die Vorerkrankungsabfragen (>1) innerhalb eines Verarbeitungslaufs wirklich rausgegangen sind (ich habe inzwischen schon Rückmeldungen dafür von KKs erhalten = es funktioniert wirklich).   Dementsprechend bedeutet dies, dass nur Dok. 9225917, Punkt 4.2 ein bisschen irreführend ist.   MfG ... Mehr anzeigen

Hallo Sue,   danke für den Hinweis! Leider ist die Umstellung bei uns technisch nicht möglich, aber gut zu wissen, dass die Bearbeitungsmethode im LG ein bisschen abweichend ist.   MfG ... Mehr anzeigen

Und auch wenn ich dann für jede der vorangegangenen Fehlzeiten die Vorerkrankungen abrufen möchte, kann ich die doch gleich im Anschluss anfragen. Bei mir klappt das.   Nur dass wir sicherlich über die selbe Thematik sprechen:   A ist meine 'Referenzperiode', zuerst frage ich ob B,C,D,E,F auf A anzurechnen sind.   Dann möchte ich wissen ob auf B Perioden C,D,E,F anzurechnen sind, usw.   Ich interpretiere die Begrenzung so, dass ab Abfrage für Referenzperiode B man das nur in einem neuen Lauf (wie Herr Lutz jetzt bestätigt hat in einer halben Stunde) anstossen kann.   Du hast Recht, dass kein Hinweis gezeigt wird, alles scheint OK zu sein, aber laut DATEV Beschreibung landet die zweite Anforderung eigentlich im Nirwana wenn sie im selben Verarbeitungslauf angestossen wird.   MfG ... Mehr anzeigen

Die LODAS-Verarbeitungen finden seit einiger Zeit zwischen 08:30 Uhr und 16:30 Uhr im 1/2-Std.-Takt statt.   Sie haben vollkommen Recht! (ich habe die Rückübertragungszeit- mit den Auslösezeitintervallen verwechselt) ... Mehr anzeigen

Hallo Flitze0815,   mein Verständnis ist, dass in meinem Beispiel ich auf einen neuen Verarbeitungslauf warten muss um die nächste Periode 01.02.-29.02.2024 abfragen zu können. Würde ich im ersten Laufzeitraum die Abfrage auch für diese zweite Periode anstossen, würde diese zweite Abfrage nie im Rechnezentrum und dementsprechend nie bei der KK ankommen.   Wenn ein Arbeitgeber eine detaillierte Analyse der zusammenhängenden oder nicht zusammenhängenden Krankheitszeiten verlangt (MA hat z.B. 12 Perioden die analysiert werden müssen), bedeutet das, dass man die Abfrage stündlich (12 mal in diesem Fall) stellen muss. Bei Gesprächen mit KK Kontaktpersonen wird immer wieder betont, dass die Zusammenhang-Diagnose von Zeitraum (a) und Zeitraum (b) mit Zeitraum (c) nicht automatisch bedeutet, dass (a) und (b) zusammenhängen - daher die Notwendigkeit separater Anfragen.   Deswegen die Frage ob ein Workaround bez. dieser Begrenzung gibt oder nicht. Danke!   MfG ... Mehr anzeigen

Hallo Frau Frohmeyer,   danke für Ihre Rückmeldung!   Letzte Frage, nur zum Verständnis: es ist dann so, dass hier keine Entwicklung (Zahl der Anforderungen / Verarbeitungslauf auf unbegrenzt setzen) geplant/möglich ist? Danke!   MfG ... Mehr anzeigen

Genau, erneute Eingabe + Abruf geht alles problemlos durch, und dann beim Statusübersicht nicht ersichtlich. Das könnte leider bedeuten (d.h. kein"Erneuter Abruf erst nach 14 Tagen möglich" Hinweis), dass die ersten Abrufe eigentlich nicht aktiv sind / können nicht aktiviert werden / sind verschwunden.   Ich habe umg. 700 Perioden mit ASCII Import hochgeladen, ich kann diese natürlich nochmals hochladen, sollte die ursprünglichen Perioden problemlos überschreiben, aber ich muss sicher gehen, dass es 'lohnt' sich das so zu machen, wenn das System wieder korrekt funktioniert. Es könnte einfach die Abfragen verdoppeln, und dann erhalte ich 700 "Erneuter Abruf erst nach 14 Tagen möglich" Hinweise, die dann vielleicht manuell bereinigt werden müssen. ... Mehr anzeigen

Hallo Mivo,   Genau, das passiert bei mir auch! Krankengeld Zeitraum wird manuell erfasst. In der Zwischenzeit wird aber das Enddatum des noch bezahlten Zeitraums durch die eAU Rückmeldung automatisch verlängert -> Überschneidung. Und Du hast Recht, bei der Erfassung des Krankengeld Zeitraums kann ich das Enddatum des bezahlten Zeitraums festschreiben, aber die Rückmeldung basiert sich noch auf die ursprünglich erfasste Periode, wo die Festschreibung noch nicht addiert wurde. Mich wundert es wirklich wieso das Thema bisher noch nicht angesprochen wurde.   MfG   ... Mehr anzeigen

Hallo Frau Frohmayer,   Vielen Dank für Ihre Antwort. Bei 8000 Mitarbeitern und bei einem Prozess-Konstellation, wo die rückgemeldete Krankheitsperioden mit einem externen Zeiterfassungssystem zu harmonisieren sind, ist die Darstellung der detaillierten Daten (im besonders das Beginndatum der Periode die durch die Folgebescheinigung und die importierte Rückmeldung automatisch verlängert wird) lediglich in dem Übernahmeprotokoll, bei den einzelnen Personalnummern praktisch nutzlos. Wäre das Beginndatum hier in dem 'Statusübersicht' Report, d.h. einfach und schnell exportierbar dargestellt, könnte der Vergleich des Ergebnisses (ursprüngliches Beginndatum - verlängertes Enddatum) mit der ursprünglichen Periode (ursprüngliches Beginndatum - ursprüngliches Enddatum) reibungslos und effizient durchgeführt werden.   Ich interpretiere Ihre Aussage so, dass eine Softwareentwicklung in dieser Richtung hier nicht geplant ist.   Überlappung: vielen Dank, ein Servicekontakt wurde geöffnet.   MfG ... Mehr anzeigen

Hallo Zusammen,   bezüglich des eAU Folgebescheinigung Updates (das Thema ist im Vergleich zum PUEG definitiv vernachlässigt 🙂 )   "Funktionale Änderung:   Elektronische Arbeitsunfähigkeitsbescheinigung (eAU) Mit LODAS 12.4 werden zurückgemeldete Folgebescheinigungen automatisch mit der davor liegenden Erkrankung zusammengefasst. Ausnahme: Wenn zwischen dem Feststellungsdatum der Folgebescheinigung und dem Ende der letzten gespeicherten Fehlzeit mehr als 6 Tage liegen, wird die Folgebescheinigung keiner bestehenden Fehlzeit zugeordnet. Im Übernahmeprotokoll wird ein entsprechender Hinweis ausgegeben."   Erste Erfahrungen:   Statt 'unvollständiger Zeitraum' (vorher bekam man diese 'Fehlermeldung' im Falle einer Folgebescheinigung), wird jetzt 'Ende der AU in vorheriger Fehlzeit korrigiert' dargestellt und ja, es ist richtig dass "zurückgemeldete Folgebescheinigungen automatisch mit der davor liegenden Erkrankung zusammengefasst (werden)" wenn das der Fall ist.   ABER:   -Im Report 'Statusübersicht' wird es nicht spezifiziert auf welche vorherige Fehlzeit und auf welches genaues Beginndatum diese sich bezieht (was eigentlich das wichtigste wäre...). Das entsprechende Feld ('AU seit') bleibt leer.   -Wenn man inzwischen AU Perioden hat (d.h. Beginndatum ist nicht identisch mit dem Beginndatum des Zeitraums was jetzt verlaengert wurde), werden diese NICHT automatisch vom System gelöscht, so das man mit überlappenden Zeiträumen bleibt!!   Siehe Screenshot: 1. Lediglich auf Grund des Reports 'Statusübersicht' weiss man nicht dass 14.06. verlängert wurde, neuer Zeitraum muss bei 'Fehlzeiten' manuell geprüft werden 2. Perioden 19.06.-23.06., 26.06.-30.06. sind als überlappenden AU Perioden drin geblieben!   Ich muss jetzt das System von diesen Duplikaten bereinigen und bei 8000 Mitarbeitern dauert das ewig (z.B. bei einer Überlappung von 'Krankheit mit Kr.Geld' + 'Entgeltfortzahlung mit AU' läuft die Abrechnung tatsächlich auf Fehler!). Gibt es eventuell eine Lösung gegen dieser Überlappung der betroffenen Zeiträumen? Der Haken bei 'Fehlzeit-Ende nicht durch eAU-Rückmeldung überschreiben' zu setzen ist für uns keine Option, wir brauchen diese Verlängerungen, sonst würde das Update eigentlich nichts bringen.   Die Hoffnung war, dass das Update den Prozess verleichtern wird, was teilweise passiert ist, da aber die AU Perioden inzwischen nicht automatisch vom System gelöscht werden, bleibt man mit einer extra Aufgabe und dann sind wir im gleichen Entwicklungsstand am Ende des Tages... (es wundert mich wirklich wieso dieser Aspekt noch nicht angesprochen wurde).   Danke!   ... Mehr anzeigen

Danke!   Dann ist denk ich Punkt 1 bestätigt -> es ist durchaus möglich eine A.Unfall Kennzeichnung als Rückmeldung zu erhalten, auch wenn der abgefragte Satz initiell nicht so gekennzeichnet wurde. Hoffentlich ist der Prozess dann nicht davon abhängig bei welcher KK die Anfrage ankommt... 🙂   Dann bleibt nur Punkt 2 offen: gibt es außer dem Haken bei 'Übersicht Rückmeldungen EEL/AAG/eAU  / Spalte 'Arbeitsunfall' ' (= bei der manuellen Prüfung der einzelnen PNR) ein anderes Feld, wo man prüfen kann ob der Satz ein A.Unfall ist oder nicht? Wie erläutert, 'Statusübersicht' enthält so eine Spalte nicht. Aber vielleicht hast / habt Du / Ihr etwas noch gefunden! Danke.   MfG ... Mehr anzeigen

Danke für Dein Input!   "...nur dann anzeigt/verarbeitet, wenn man dazu auch eine Anfrage mit der Angabe Arbeitsunfall abgeschickt hat"   Genau, das ist der Kernsatz und die wichtigste Frage für mich hier. Der Kunde möchte bei uns die Verantwortung   1. der tatsächlichen Eingabe des Unfalles und 2. der Prüfung/Bestätigung ob es ein Arbeitsunfall war oder nicht   an uns verschieben. Deswegen wäre es wichtig zu wissen, ob das eigentlich technisch möglich ist, oder ob der Datenaustausch nur dann korrekt initiiert werden kann, wenn der erster Abruf schon diese extra Kennzeichnung ('Arbeitsunfall') enthält      "Wenn die Krankenkasse eine eAU mit Arbeitsunfall zurückmeldet und das nicht bei DATEV so ankommt und dargestellt wird, liegt das Problem wohl eher bei LODAS/LuG."   Wenn Punkt 1. erledigt ist, dann kommen wir zum Problem Nr. 2. -> die Darstellung der Rückmeldung: wie gesagt, es wird dargestellt, aber nur unter 'Übersicht Rückmeldungen EEL/AAG/eAU', Spalte 'Arbeitsunfall', und das kann man leider nur händisch abrufen. Bei Statusübersicht (und dementsprechend im Export .csv Datei) gibt es keine solche Kennzeichnung. Bei 8000 MAn ist es nicht möglich die einzelen Personalnummern unter 'Übersicht Rückmeldungen EEL/AAG/eAU', Spalte 'Arbeitsunfall' individuell zu prüfen.     "Hast du denn den Abruf nochmal mit der Angabe Arbeitsunfall gemacht und dann kam die Rückmeldung wie erwartet zurück? Mach es einfach mal, wenn noch nicht geschehen."   Ich versuche das und melde mich 🙂 Der Fall war ein bißchen komplizierter, da auch  die Zeiträume nicht stimmten, aber ich habe nun die Abfrage auch mit der - höchstwahrscheinlich - korrekten Periode + als Unfall nochmals abgerufen.   MfG ... Mehr anzeigen

Hallo Zusammen,   danke, aber sind wir sicher, dass das auch in der Praxis so aussieht? Ich habe Fälle wo nach der Eingabe "Entgeltfortzahlung mit AU-Bescheinigung" die Rückmeldung "keine AU" von der KK zur Verfügung gestellt wurde. Im nachträglichen Telefongespräch habe ich aber dann die Erläuterung erhalten, dass der AN eigentlich einen Arbeitsunfall hatte   ->    bei mir in der Praxis sieht das momentan so aus, dass dieser Satz "Also nein, der AG muss nur das Datum angeben. Alles andere wird zurückgemeldet." nicht völlig richtig ist.   Meine Erfahrung: also nur wenn der AG selbst die Periode als Arbeitsunfall an die KK meldet, kann ein erfolgreicher Datenaustausch stattfinden!   Habt Ihr vielleicht ähnliche (ODER umgekehrte) Erfahrungen damit? Ehrlich gesagt würde ich mich eher für die umgekehrte Version freuen 🙂 , jedoch weiss ich eigentlich nicht wie genau ein Arbeitsunfall bei 'Statusübersicht' gekennzeichnet wird, es gibt keine Spalte auf Grund wessen die Arbeitsunfälle leicht identifiziert/gefiltert werden können (Ich dachte dass dies vielleicht die Spalte 'Meldung KK/DATEV' sein könnte, aber im Dok. Nr. 1024188 ist es klar bestätigt, dass 'Arbeitsunfall' nicht eine Option ist).   Die Rückmledung enthält eine Info bezüglich eines Arbeitsunfalls nur bei 'Übersicht Rückmeldungen EEL/AAG/eAU', Spalte 'Arbeitsunfall', d.h. dass wenn man die Arbeitsunfälle prüfen möchte, dies nur bei den einzelnen Personalnummern durchgeführt kann, Statusübersicht enthält diese Info tatsächlich nicht.   Danke im vorab, vielleicht gibt es hier trotzdem eine 'automatisierte' Lösung...  Mfg ... Mehr anzeigen

Hallo Christopher_Fürther,   vielen lieben Dank! Ein Servicekontakt wurde jetzt im betroffenen Thema geöffnet.   MfG ... Mehr anzeigen

Hallo Zusammen,   im Bezug auf das Thema ASCII Übernahme und Dok.-Nr.: 9294677, Punkt 4.5: Nach dem ASCII Import konnten wir bei 'Mitarbeiter Elektronische Arbeitsunfähigkeitsbescheinigung /Abfrage senden' die eingespielten Werte aller Mitarbeiter finden. Wenn wir aber die Abfrage tatsächlich anstossen wollten, haben wir die folgende Fehlermeldung erhalten:   "#LO60222 - Es ist ein Fehler beim Konvertieren der Daten für das Rechenzentrum aufgetreten. Die Übertragung an das RZ konnte deshalb nicht durchgeführt werden"   Gibt es vielleicht eine Obergrenze für die Menge der abfragbaren Daten? Hat jemand hier schon eine ähnliche Fehlermeldung im System erhalten / Erfahrungen damit?   Im aktuellen Fall geht es um umg. 600 Krankheitssätze. Diese Menge wird aber z.B. bei einem anderen durch uns betreuten Mandanten warscheinlich viel höher sein. Dementsprechend möchten wir das auch für die Zukunft genauer haben. Ich würde mich über irgendwelche Lösungsvorschläge freuen. Vielen Dank im vorab!   MfG ... Mehr anzeigen

Hallo Metalposaunist,   Dafür (pers. Lohndokumente online anzuschauen) hat der Kunde eine separate Oberfläche entwickelt, die schon vor der DATEV Übernahme von den MAn benutzt wurde.   Danke, LG ... Mehr anzeigen

Hallo Zusammen!   Bedeutet aber das hoffentlich nicht, dass auch bei diejenigen, die früher (fälschlicherweise!) einen Registrierungsbrief erhalten haben und darauf - in unserem Fall korrekt! - nicht reagiert haben, dies jetzt nochmals an den Mitarbeiter versendet wird? Bei den betroffenen Mitarbeitern haben wir in unserem Fall das Freischaltungsende auf xx.xx.xxxx gesetzt, um die weitere Kommunikation zwischen DATEV und MA zu vermeiden.   Hintergrund: bei uns möchte der Kunde KEINEN AN Zugriff den Mitarbeitern zur Verfügung stellen, da aber DATEV (LODAS) trotz MandantenEinstellungen dies in einigen Fällen falsch mit einem Registrierungsbrief angestossen hat, mussten wir nachhacken. Dies ist ein wirklich kritisches Thema bei uns und der DATEV Systemfehler hat zahlreichen Eskalationen ausgelöst...   Hoffentlich stosst das Update den Versand jetzt nicht nochmals an, oder?   Vielen lieben Dank im vorab! ... Mehr anzeigen