Wir können alle dazu beitragen, dass aus den 1% fehlerhaften Meldungen, 10% werden. Lasst uns unseren Teil beitragen und stumpfsinning alles mitmachen, was irgendjemand ohne Praxiswissen festlegt.
@CHGB schrieb:Ich sehe ja schon immer die Problematik eine Kundenadresse vollständig zu erfassen. Viele Straßenadressen sind (viel) länger als die Felder in Datev es erlauben.
Bonus-Runde: LODAS wirft bei -Straße grundsätzlich einen Adressfehler. Weil ich mich weigere -Strasse zu schreiben (Adressen sind doch keine Glitzersteinchen!), kürze ich also immer mit -Str. ab.
@Wuppergirl, meine Eltern haben zum Glück damals bewusst darauf verzichtet bei uns (jeweils zwei Vornamen) einen Rufnamen festzulegen. Aber absurd sind die ganzen Beschränkungen manchmal, ja. Ich amüsiere mich auch immer wieder über Formulare, in denen man auf _____ <- so viel Platz die Rufnummer eintragen soll.
Hallo Herr Seemann,
auch ich gehöre zu den Dinos und habe fast 40 Jahre Lohn hinter mir. Ich habe nun meine Konsequenzen gezogen weil ich den Stress und die dauernden Windungen nicht mehr mitmachen kann, dazu fehlt mir das Nervenkostüm. Also habe ich zum Jahresende gekündigt und arbeite die letzten drei Jahre in einem anderen Beruf. Irgendwann will keiner mehr die Arbeiten machen, weil zu aufreibend s.o.) etc. ... aber dann gibt es bestimmt die KI.
Grüße
M_H
@rschoepe schrieb:
Bonus-Runde: LODAS wirft bei -Straße grundsätzlich einen Adressfehler.
Nö - ich schreibe Straße grds. mit ß aus - und das hat bisher noch nie zu Fehlern geführt.
Hallo rschoepe,
das mit der Straße kann ich nicht bestätigen. In unserem Hause wird immer auf eine gute Stammdatenpflege geachtet. Und die Adressen lauten immer exakt so, wie es die Post im im PLZ-Server https://www.postdirekt.de/plzserver/ vorgibt, da hier auch genau die Adressdatenbank dahinter steht, die auch die DATEV im Lohn RZ verwendet. Vielleicht hilft es Ihnen, wenn Sie mal einen Vergleich mit dem Server vornehmen.
Ich habe mir mal meine Mandanten Adressen angesehen und auch einige mit XX-Straße gefunden. Da beschwert sich LODAS aber nie! Der Fehler kommt aber auch schon, wenn die Schreibweise nur um ein Zeichen von derjenigen in der Datenbank abweicht.
Viel ärgerlicher ist die Sache mit dem Mandantennamen. LODAS kann maximal 36 Zeichen auf den Auswertungen darstellen, alles weitere wird dumpf abgeschnitten. Also müssen Sie den Stammdatenabgleich abschalten und manuell in LODAS möglichst sinnvoll auf 36 Zeichen abkürzen, damit es nicht wie in den Siebzigern aussieht.
@M_H schrieb:Also habe ich zum Jahresende gekündigt und arbeite die letzten drei Jahre in einem anderen Beruf.
Oh. Dann machen Sie mal Berufsberatung.😀 Darf ich fragen, was Sie dann jetzt machen? Ich wollte ja schon gebogene Sechskantschlüssel und andere Werkzeuge sortieren, aber was macht man sonst so als frustrierter Lohnbuchhalter. 😁
@Uwe_Lutz schrieb:
Nö - ich schreibe Straße grds. mit ß aus - und das hat bisher noch nie zu Fehlern geführt.
Hm, dann muss ich nochmal schauen. Ich hatte zwischendrin für eine Weile das beschriebene Problem.
Und dabei war ich dann erstmal geblieben. Wir haben auch bei einer ganzen Reihe von AN die Schreibweise mit "Strasse", kann also nicht nur ich das Problem gehabt haben. Wobei die Kolleginnen es auch nicht immer so genau mit der Rechtschreibung nehmen …
@rschoepe Vielleicht liegt es dann an der Schreibweise vor der Straße. Denn ich schreibe hier die Straße grundsätzlich aus und hatte diesbezüglich noch nie Probleme.
@tbehrens Ich habe auch einen Fall, da hatte ich zunächst nur Angaben vom Arbeitgeber. Steuer-Id passte nicht. Ich fragte daher genauer nach und bekam abfotografierte Dokumente mit all den Daten. Steuer-Id hatte einen Zahlendreher, die passte dann.
ABER: das Geburtsdatum war ein komplett anderes und somit habe ich auch jeden Monat die Meldung, dass das nicht zusammen passt. Gottseidank kann man trotzdem die Abrechnung machen.
@rschoepeschrieb:
Bonus-Runde: LODAS wirft bei -Straße grundsätzlich einen Adressfehler. Weil ich mich weigere -Strasse zu schreiben (Adressen sind doch keine Glitzersteinchen!), kürze ich also immer mit -Str. ab.
Straße mit "ß" ist in Deutschland richtig:
https://de.wiktionary.org/wiki/Straße
In der Schweiz und in Liechtenstein dagegen:
https://de.wiktionary.org/wiki/Strasse
N'Abend,
spannend wird es, wenn jemand zwei unterschiedliche Geburtsdaten (für SV-Meldungen und ElStam) hat. Den Fall hatte ich.
Flüchtling. Bei der Einreise (vermutlich ohne Papiere) wurde die eine Nummer auf Basis eines fiktiven Geburtsdatums vergeben, die zweite dann aufgrund des echtens (nachdem er Papiere hatte?).
Ich durfte dann (Fremdprogramm) beim Versenden der LStB dann immer vorher erst das Geburtsdatum im Mitarbeiterstamm ändern. Sonst wäre ich nämlich in Verfahrenshinweis 552020202 gelaufen (Arbeitnehmer undbekannt)....
Gruß, vw
@SusanneR, die war jeweils gleich, ich hatte zwischen den einzelnen Probeabrechnungen nur die Schreibweise/Abkürzung von Straße geändert. ¯\_(ツ)_/¯
Moin,
hier geht es doch eigentlich um das Thema "Abfrage der Versicherungsnummer".
Sollten wir es hier nicht bei dem Problem belassen? Das hierfür auch die Adresse wichtig ist, ist ja auch richtig. Aber hier geht es doch um den Haken "Versicherungsnummer abfragen", oder?
Viele Grüße
@t_r_ ... Buchhaltung 😂
die ist deutlich entspannter
... ach ja, und wenn das auch nicht klappt mache ich eben Hundesitting 😁
Das die Adresse zur Abfrage der Versicherungsnummer wichtig ist ist Schwachsinn in Dosen.
Manche Leute wechseln Ihre Adresse wie andere Sommer und Winterreifen. Es wäre schon Zufall wenn die vom AN angegebene Adresse immer identisch mit der bei der DRV gespeicherten wäre. Mal ganz unabhängig von der Schreibweise des Straßennamens.
Die MA wissen oft selber nicht, wie der Straßenname richtig geschrieben wird. Ich gehe daher bei Neuanlagen mittlerweile immer auf die Seite der Deutschen Post um die richtige Schreibweise zu haben. Und oft sind die PLZ auch falsch oder nicht im Fragebogen eingetragen 🙈
Die Adresse ist schon wichtig, sofern ich keine Versicherungsnummer habe.
Ich finde eine Automatische Abfrage der Versicherungsnummer unnütz.
Und darum geht es hier doch eigentlich, oder?
@M_H schrieb:@t_r_ ... Buchhaltung 😂
Ihhhh. 🤣 Ich hoffe dann wenigstens Debitor A bia A oder ähnliches und nicht im Stb.. Ich dachte, es oll ruhiger werden. 🤣
die ist deutlich entspannter
... ach ja, und wenn das auch nicht klappt mache ich eben Hundesitting 😁
Das dann eher, viel frische Luft und Bewegung. 😁
@t_r_ definitiv kein StB mehr, Harakiri habe ich genug hinter mir, da kann die Kugel ab 01.01. nur ruhiger laufen. 😏
@M_H schrieb:@t_r_ definitiv kein StB mehr, Harakiri habe ich genug hinter mir, da kann die Kugel ab 01.01. nur ruhiger laufen. 😏
👍👏😀
Und da diskutieren Politiker darüber, wie man mehr Menschen zum Arbeiten motivieren kann. Eine Möglichkeit wäre, es bei der Gesetzgebung den damit Arbeitenden nicht zu schwierig zu machen. 😁
Richtig! Ich verstehe das vermüllen solcher Threads auch nicht. Aber das geht ja schon Jahre so.
@cro ,
jo, deshalb höre ich jetzt auch damit auf - geht mich eh alles nix mehr an 😁
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!
Ich bin Ende 2018 auch weg vom StB, aber im Lohn geblieben ... Inzwischen in einem Unternehmen mit rund 80 personalführenden Unternehmen ... das ist dann auch nicht viel anders als beim StB, weil auch hier diverse GF meinen, dass sie das anders machen (müssen) als die anderen Gesellschaften ... aber Spaß macht es trotzdem - irgendwie
hier geht es doch eigentlich um das Thema "Abfrage der Versicherungsnummer".
Einverstanden. Ich habe das eben mal in LuG über den Weg "Abrechnung | DEÜV-Versicherungsnummernabfrage" versucht. Der September ist noch nicht abrechnet, Abfrage für neuen MA ab 01.10.2024 führt zu
Fehler #LN24511
Für die Anfrage der Versicherungsnummer ist eine Betriebsnummer des Arbeitgebers / Verursachers anzugeben.» Erfassen Sie eine Betriebsnummer bzw. ordnen Sie den Mitarbeiter einem Beschäftigungsbetrieb zu und wiederholen Sie die Meldungserstellung über Abrechnung | DEÜV-Versicherungsnummernabfrage.
Vollkommen sinnfreie Fehlermeldung. Nach Monatsabschluss 09 geht die Abfrage dann doch. Immerhin ist soeben auch die SV-Nr. nach 5 min zurückgemeldet. Wenigstens das klappt.
Bei den vielen Nachrichten habe ich den Überblick verloren.
Hat die DATEV bereits Stellung genommen? Das war doch für diese Woche angekündigt.
Nö, aber eine Email habe ich schon bekommen, ob mir geholfen wurde 😅
Guten Tag Herr Klimm,
so mit LOGE habe ich das mal ausprobiert.
Geburtsname unbekannt, es kam nach 1 Stunde eine Rückmeldung, aber mit Hinweis:
Hinweis #LN09236
Bei der Abfrage der Versicherungsnummer vom 11.10.2024 wurde kein Ergebnis von der Deutschen Rentenversicherung
zurückgemeldet. Das Verfahren zur Vergabe einer Sozialversicherungsnummer wird über die DEÜV-Anmeldung (Grund der
Abgabe 10) eingeleitet. Eine DEÜV-Anmeldung (Grund der Abgabe 10) wird automatisch bei der Abrechnung des Mitarbeiters
oder manuell im Mitarbeiter unter Abrechnung | DEÜV-Meldung erstellt.
Dann nochmal, wenn ich das Feld leer lasse unter Geburtsname.
Hat das Programm dennoch gesendet und nach 15 min. kam folgender Hinweis:
Hinweis #LN09236
Bei der Abfrage der Versicherungsnummer vom 11.10.2024 wurde kein Ergebnis von der Deutschen Rentenversicherung
zurückgemeldet. Das Verfahren zur Vergabe einer Sozialversicherungsnummer wird über die DEÜV-Anmeldung (Grund der
Abgabe 10) eingeleitet. Eine DEÜV-Anmeldung (Grund der Abgabe 10) wird automatisch bei der Abrechnung des Mitarbeiters
oder manuell im Mitarbeiter unter Abrechnung | DEÜV-Meldung erstellt.
Sicher ich habe mir die RV-Nr. geben lassen, aber ganz ehrlich, sollte das Feld wirklich wie es geplant ist wegfallen, sehe ich ein viel schlimmeres Chaos.
Gruß nh
Nachtrag:
Haha, der Mandant hat mir ein falsche Geburtsdatum gegeben, wo ich gerade die RV-Nr. eintippe...
Haha, der Mandant hat mir ein falsche Geburtsdatum gegeben, wo ich gerade die RV-Nr. eintippe...
der Fehler "falsche SV-Nr." wird ersetzt durch "falsche Vergabe neuer SV-Nr." Die Fehlerquelle Mensch bleibt gleich, es gibt dann einfach nur mehr Daten(felder) die falsch sein können. Diese zusätzlichen Fehlerquellen haben aber wenigstens keine Prüfsumme wie die SV-Nr. Ich sehe da kein Problem.
11.10.2024
15:30
zuletzt bearbeitet am
11.10.2024
15:34
von
Nadine_Mack
Hallo Community,
nochmal Danke für Eure zahlreichen Beiträge und Recherchen zum Thema der verpflichtenden Abfrage der Versicherungsnummer.
Rechtliche Vorgaben zur Umsetzung in den Lohnprogrammen:
Die rechtlichen Grundlagen sind hier im Thread bereits gut dargestellt worden: § 28a Abs. 3a SGB IV in Verbindung mit dem 8. SGB IV-Änderungsgesetz und dem Pflichtenheft der ITSG.
Ausschlaggebend für die Änderung in den Lohnprogrammen war die Ergänzung im Pflichtenheft. Dieses Pflichtenheftkriterium ist sehr trivial formuliert und hinterlässt damit auch viel Interpretationsspielraum. Sinngemäß ist die Versicherungsnummer vor einer DEÜV-Anmeldung elektronisch abzufragen, sofern sie programmseitig nicht vorliegt.
Was uns seit letztem Jahr vor große Herausforderung gestellt hat, war eine praxistaugliche Programmlösung mit der ITSG zu finden, die auch der rechtlichen Vorgabe genügt. Ich kann euch versprechen, dass wir uns das nicht einfach gemacht haben. Wir haben in vielen Gesprächen Eure Praxisperspektive einfließen lassen.
Für uns war es wichtig eine möglichst flexible Programmlösung auszuliefern, die zwar für den Standardprozess Rechtssicherheit gibt, aber für Ausnahmefälle durchaus Alternativen ermöglicht.
Letztlich liegt die rechtliche Auslegung aber bei euch als Lohnabrechner! Auch bleibt abzuwarten, wie sich das Thema in der Prüfungspraxis entwickelt und entsprechende Nachweise geprüft und vorgelegt werden müssen.
Uns ist bewusst, dass mit den Geburtsangaben, die für die Abfrage der Versicherungsnummer notwendig ist, zusätzliche Informationen eingegeben werden müssen und diese damit zu Pflichtfeldern werden
Was hat sich in den Lohnabrechnungsprogrammen LODAS und Lohn und Gehalt geändert?
Das Feld Versicherungsnummer fällt nur im Fenster Mitarbeiter neu weg (LODAS seit Service-Release 02.10.2024 / Lohn und Gehalt zum Service-Release im Jahreswechsel). In den Stammdaten für den Mitarbeiter findet Ihr das Feld für die SV-Nummer wie gewohnt.
Diese Felder bleiben weiterhin bestehen und gewährleisten, dass die Versicherungsnummer z.B. aus einem Vorprogramm importiert werden kann. Wenn nicht klar ist, ob im Vorprogramm eine Versicherungsnummernabfrage erfolgt ist, empfehlen wir die zusätzlichen Daten für die Abfrage zu erfassen und die Abfrage zu starten:
Wenn die Versicherungsnummernabfrage über ein anderes Programm (z. B. SV-Meldeportal) durchgeführt wird, kann das Kontrollkästchen Versicherungsnummernabfrage deaktiviert und die Versicherungsnummer weiterhin manuell erfasst werden.
Personalfragebögen:
Im Dokument 1035006 findet Ihr voraussichtlich ab nächster Woche die aktuellen Personalfragebögen. Die Fragebögen werden an die Anforderungen der Versicherungsnummernabfrage angepasst. Bitte entschuldigt die verzögerte Bereitstellung der Personalfragebögen.
Euer Feedback werden wir weiterhin berücksichtigen und prüfen wie und wo wir unsere Lösungen noch verbessern können.
Viele Grüße
Arthur Roth
Product Owner, Produktentwicklung LODAS