Hallo Community,
wir setzen seit vielen Jahren LODAS ein. Nun mussten wir unterjährig wegen eines plötzlichen Personalausfalls beim Mandanten ein Baulohnmandat übernehmen, das auf L+G abgerechnet wird. Um keine Verzögerung zu verursachen haben wir deshalb dieses Mandat auf L+G belassen. Nach ein paar Baulohnabrechnungen damit, waren meine Mitarbeiter der Meinung (zumindest bei Baulohn) sei L+G deutlich weniger fehleranfällig und einfacher zu bedienen als LODAS. Da wir auf keinen Fall die beiden Programme dauerhaft nebeneinander nutzen wollen, stehen wir jetzt vor der Frage, einen Komplettumstieg der Kanzlei auf L+G durchzuführen.
Deshalb meine Frage in die Runde.
Die Einschränkungen von L+G (öff. Dienst, Heuer, etc.) sind nicht unser Problem - solche ko-Kriterien sind bei uns nicht im Einsatz, auch keine Mandate >1000 Mitarbeiter. Mich schreckt auch der damit verbundene Aufwand nicht -° den betrachte ich eher als Maßnahme der Qualitätssicherung, weil langjährig Eingefahrenes einfach nochmal angeschaut und überdacht werden muss. Mir geht´s hauptsächlich um die Erfahrungen, die andere "Umsteller" evtl. schon gemacht haben und deshalb zu berücksichtigen sind.
Gelöst! Gehe zu Lösung.
Guten Morgen,
wir haben vor über 15 Jahren auf Lohn und Gehalt umgestellt und die Umstellung bisher nicht bereut. Wichtig finde ich für Lodas-Gewöhnte folgende Punkte:
- vorher Gedanken um die Lohnarten machen,
- vorher Geschäftsstellen bei den Krankenkassen in der Institutionsverwaltung anlegen,
- Dokument Datenübernahme aus LODAS nach Lohn und Gehalt - Ablauf Erstbestückung beachten.
Man muss sich daran gewöhnen, dass man im Gegensatz zu Lodas einen historischen Verlauf selbst pflegt und daher in der Regel keine Daten mehr im Programm überschreibt.
Folgende Punkte gibt es in Lodas, die ich auch gerne in Lohn und Gehalt hätte:
- automatische Abrechnung, (dafür gibt es aber mandantenübergreifende Abrechnungsmöglichkeiten) und
- Unterdrückungsmöglichkeit der Brutto-/Netto-Abrechnung bei gleichen Auszahlungsbetrag.
Bei größerer Abrechnungsanzahl dauert die Abrechnungszeit gefühlt sehr lang. Ich habe das noch nicht gestoppt, aber bei 100 bis 200 Abrechnungen mehrere Minuten. In dieser Zeit ist der PC trotz ASP auch langsamer.
Wenn die Möglichkeit bestände, würde ich mir ggf. heute überlegen, ob ich nicht mit beiden Programmen arbeiten würde.
Viele Grüße
T. Reich
Hallo Herr Renz,
ich kann mich den positiven Erfahrungen von Herrn Reich nur anschließen ...
Wir rechnen schon seit 1996/1997 mit LuG ab. Die höhere Flexibilität (mehr als zwei Abrechnungsläufe etc.) erkauft man sich aber z.B. damit, dass die eigentliche Abrechnung anders als unter LODAS/RZ abläuft und - da lokal gerechnet wird - auch nicht mit dem Tempo eines Nürnberger Großrechners mithalten kann. Im Lohn laufen eben komplexe Berechnungen zuhauf ab, die bei uns im Regelfall pro AN mit ca. 5 Sekunden zu Buche schlagen. Hinzu kommt dann auch noch der separat anzustossende Monatsabschluss, der je nach Umfang der genutzten Funktionalitäten auch seine Zeit braucht (bei ca. 100 AN bei uns etwa 3 - 4 Minuten, wobei wir praktisch alle Automatisierungsmöglichkeiten dort auch verwenden). Dafür haben Sie aber eine einzelne Probeabrechnung praktisch sofort am Bildschirm.
Alles in Allem würde bei uns sicher niemand ernsthaft über den Weg zurück nachdenken wollen. Wir haben uns angewöhnt, in den genannten Wartezeitfenstern einfach die anderen Nebentätigkeiten (z.B. Archivierung der vom Mandanten angelieferten Belege im DMS etc.) zu erledigen. So kann man durch kleinere Anpassungen im Bearbeitungsablauf diese Zeiten praktisch eliminieren.
Lediglich den Hinweis von Herrn Reich auf die Krankenkassen-Geschäftsstellen würde ich so heute nicht mehr geben wollen, denn der ursprüngliche Zweck (direkte Zusendung der Daten an den Sachbearbeiter der Kasse vor Ort) für diese Geschäftsstellen wurde durch eine Kehrtwende der SV (Zentralisierung des kompletten Dateneingangs) hinfällig, so dass wir für neu hinzukommende Kassen nun lediglich noch die automatisch erfolgende Vergabe einer einzigen "fiktiven" Geschäftsstelle verwenden.
Dort, wo wir in der Vergangenheit individuelle Geschäftsstellen angelegt hatten, lassen wir diese "laufen", da eine Zusammenführung nur für die Zukunft gelten würde, die "alten" Geschäftsstellen aber sowieso nicht aus dem System entfernt werden können.
Wenn bei einem Mandat eine Kasse hinzukommt, bei der wir früher mehrere Geschäfts-stellen schon angelegt hatten, verwenden wir grundsätzlich immer nur noch die Nr. 1 weiter.
Für den Umstieg würde ich nicht den Jahreswechsel wählen, um mögliche "Verluste" bei den SV-Meldungen zum Jahresende erst gar nicht zu provozieren. Und vielleicht starten Sie auch zuerst mit den "einfachen" Lohnmandaten (bei uns waren das damals die Kanzleigehälter und Mandanten mit praktisch "Nur-Gehalt-Beziehern") und ziehen die anderen sukzessive nach. So können sich die Sachbearbeiter an die neue Logik heran arbeiten und kommen nicht gleich zu Beginn unter Termindruck ...
Wir hatten damals grundsätzlich nach der Novemberabrechnung die Übernahme vollzogen, wobei zu beachten ist, dass Nachberechnungen in LuG nur für die in diesem Programm auch abgerechneten Monate möglich ist. D.h. in meinem Beispiel waren nach dem Umstieg Nachberechnungen erstmals für den Dezember in LuG möglich. Korrekturen für Vormonate (im RZ abgerechnet) müssten Sie daher in den Dezember packen und gegebenenfalls ein Auge darauf werfen, dass dabei auch die zutreffenden Beiträge zur SV entstehen (wenn "nur" Einmalbezüge nachzuberechnen sind, ist das aber kein Problem, da die Jahresumrechnung dann mit den historischen kumulierten Werten läuft - bei laufenden Bezügen des Novembers oder der Vormonate könnte es aber durch die monatliche BBG zu einem abzugsfreien Überhang kommen - da müssten Sie dann nach Kontrolle der Probeabrechnung noch Hand anlegen). Alternativ könnten Sie auch den Umstieg nach der Januarabrechnung machen, dann haben Sie aber keine Nachberechnungsmöglichkeit für das Vorjahr in LuG.
Das Grundproblem hat man aber bei jedem (unterjährigen) Systemwechsel ...
Herzliche Grüße und gutes Gelingen ...
R. Hein