KK Stammdatenimport
-
- Beiträge: 265
- Registriert: 06.04.2009 11:32
- Wohnort: SL
- Abrechnungssystem: LOGA
- Payroll: Ja
- Hochrechnung: Nein
- Zeitwirtschaft: Nein
- HCM: Ja
- Stellenplan: Ja
- Auswertungsgenerator: Ja
- Analyse: Nein
- Archiv: Ja
- Firma:
- Branche:
KK Stammdatenimport
Hallo,
Ich bin gerade wieder einmal über die KK und den Stammdaten Import gestolpert.
Ich bin kein Personaler, deshalb die Frage:
Wir importieren jeden Monat die Datei wegen der Änderungen bei den Sätzen, das finde ich soweit okay.
ABER
1. Gibt es einen plausiblen Grund warum die Fusionen nicht automatisiert laufen und man das manuell machen muss?
2. Wenn ich eine KK auf "aktiv" setze warum muss ich diese wieder in den KK-Arbeitgeber und "Empfänger" anlegen?
Es gibt hier so viel Müll und alte Bezeichnungen, Adressen Bankverbindungen etc (die nicht mit dem Import aktualisiert werden) das einem Angst und Bange wird, Fehlerquellen ohne Ende.
Mein Vorschlag -> die IK-Nummer der KK sind eindeutig das als primäres Kennzeichen zu benutzen und alle Daten darüber mit dem Import zu aktualisieren.
Dann müssen nur noch wenige Daten gesteuert werden.
Gruß Mueller
Ich bin gerade wieder einmal über die KK und den Stammdaten Import gestolpert.
Ich bin kein Personaler, deshalb die Frage:
Wir importieren jeden Monat die Datei wegen der Änderungen bei den Sätzen, das finde ich soweit okay.
ABER
1. Gibt es einen plausiblen Grund warum die Fusionen nicht automatisiert laufen und man das manuell machen muss?
2. Wenn ich eine KK auf "aktiv" setze warum muss ich diese wieder in den KK-Arbeitgeber und "Empfänger" anlegen?
Es gibt hier so viel Müll und alte Bezeichnungen, Adressen Bankverbindungen etc (die nicht mit dem Import aktualisiert werden) das einem Angst und Bange wird, Fehlerquellen ohne Ende.
Mein Vorschlag -> die IK-Nummer der KK sind eindeutig das als primäres Kennzeichen zu benutzen und alle Daten darüber mit dem Import zu aktualisieren.
Dann müssen nur noch wenige Daten gesteuert werden.
Gruß Mueller
-
- Beiträge: 265
- Registriert: 06.04.2009 11:32
- Wohnort: SL
- Abrechnungssystem: LOGA
- Payroll: Ja
- Hochrechnung: Nein
- Zeitwirtschaft: Nein
- HCM: Ja
- Stellenplan: Ja
- Auswertungsgenerator: Ja
- Analyse: Nein
- Archiv: Ja
- Firma:
- Branche:
Re: KK Stammdatenimport
Zu Punkt 1 gibt es bereits eine Lösung von P&I
ASP steuern
SV Sozialversicherung (AG-KK,KV-Umlage)IPAY
KKAUTOFU auf "Yes"
ASP steuern
SV Sozialversicherung (AG-KK,KV-Umlage)IPAY
KKAUTOFU auf "Yes"
-
- Beiträge: 139
- Registriert: 28.01.2013 13:51
- Hochrechnung: Nein
- Zeitwirtschaft: Nein
- HCM: Nein
- Stellenplan: Nein
- Auswertungsgenerator: Nein
- Analyse: Nein
- Archiv: Nein
- Firma:
- Branche:
Re: KK Stammdatenimport
Hallo Mueller,
also - wie genau das mit dem geschilderten ASP funktionieren soll - keinen Schimmer.
Problem:
a.) wird dann die ev. neue KK automatisch auf "Aktiv" gesetzt?
b.) Wird die alte Kasse auf automatisch "Inaktiv" gesetzt?
c.) Woher kommt die Info des durchgeführten Fusionsergebnisses? (Protokoll)
d.) Wenn neue KK - dann neuer Empfänger! (Ich brauche ja auch die jeweiligen individuellen
Bankdaten, Sachbearbeiter etc.)
e.) KK AG Daten müssen neu angelegt und auch manuell angepasst werden. Je nachdem, wie
U1/U2 (betriebsindividuell) gesteuert sind. (Idee wäre hier höchstens, dass P+I ab den
Zeitpunkt, ab welchem die neue KK gilt, die Felder für Umlage entsprechend gefüllt werden
müssen.
Somit ist nach der bisherigen Programmlogik klar, dass es hier 2 zusätzliche (Empfänger/KK-AG)
gibt.
lg
admin1984
also - wie genau das mit dem geschilderten ASP funktionieren soll - keinen Schimmer.
Problem:
a.) wird dann die ev. neue KK automatisch auf "Aktiv" gesetzt?
b.) Wird die alte Kasse auf automatisch "Inaktiv" gesetzt?
c.) Woher kommt die Info des durchgeführten Fusionsergebnisses? (Protokoll)
d.) Wenn neue KK - dann neuer Empfänger! (Ich brauche ja auch die jeweiligen individuellen
Bankdaten, Sachbearbeiter etc.)
e.) KK AG Daten müssen neu angelegt und auch manuell angepasst werden. Je nachdem, wie
U1/U2 (betriebsindividuell) gesteuert sind. (Idee wäre hier höchstens, dass P+I ab den
Zeitpunkt, ab welchem die neue KK gilt, die Felder für Umlage entsprechend gefüllt werden
müssen.
Somit ist nach der bisherigen Programmlogik klar, dass es hier 2 zusätzliche (Empfänger/KK-AG)
gibt.
lg
admin1984
-
- Beiträge: 265
- Registriert: 06.04.2009 11:32
- Wohnort: SL
- Abrechnungssystem: LOGA
- Payroll: Ja
- Hochrechnung: Nein
- Zeitwirtschaft: Nein
- HCM: Ja
- Stellenplan: Ja
- Auswertungsgenerator: Ja
- Analyse: Nein
- Archiv: Ja
- Firma:
- Branche:
Re: KK Stammdatenimport
Guten Morgen admin1984,
das hat mir die P&I nicht mitgeteilt, ich habe den ASP gesteuert und werde heute mal KK-Beitragssätze importieren und schauen was passiert. Aber alles berechtigte Einwände, ich hänge sie im Ticket mal an und schaue was P&I sagt.
Gruß Mueller
das hat mir die P&I nicht mitgeteilt, ich habe den ASP gesteuert und werde heute mal KK-Beitragssätze importieren und schauen was passiert. Aber alles berechtigte Einwände, ich hänge sie im Ticket mal an und schaue was P&I sagt.
Gruß Mueller
-
- Beiträge: 129
- Registriert: 16.11.2017 10:34
- Abrechnungssystem: Loga
- Payroll: Ja
- Hochrechnung: Ja
- Zeitwirtschaft: Nein
- HCM: Nein
- Stellenplan: Ja
- Auswertungsgenerator: Ja
- Analyse: Ja
- Archiv: Ja
- Sonstige: Loga@Mail
- Firma:
- Branche: ö.D.
Re: KK Stammdatenimport
Guten Morgen,
ich habe gerade dieses Thema mit Interesse gelesen. Gibt es inzwischen hierzu von P&I eine weitere Aussage (Stichwort erwähnte Ergänzung Feedback)?
Was mir etwas komisch vorkommt - Steuerung des Parameters mit Wert "Yes". Wirklich? Hätte hier eher ein deutsches "Ja" erwartet. Oder fängt P&I jetzt an die ganze Software auf englische Sprache umzustellen? Logapedia gibt hier mal wieder, hier auch zu diesem Parameter, "Null-Komma-Null" Auskunft zum Sinn oder Unsinn dieses Parameters.
ich habe gerade dieses Thema mit Interesse gelesen. Gibt es inzwischen hierzu von P&I eine weitere Aussage (Stichwort erwähnte Ergänzung Feedback)?
Was mir etwas komisch vorkommt - Steuerung des Parameters mit Wert "Yes". Wirklich? Hätte hier eher ein deutsches "Ja" erwartet. Oder fängt P&I jetzt an die ganze Software auf englische Sprache umzustellen? Logapedia gibt hier mal wieder, hier auch zu diesem Parameter, "Null-Komma-Null" Auskunft zum Sinn oder Unsinn dieses Parameters.
-
- Beiträge: 129
- Registriert: 16.11.2017 10:34
- Abrechnungssystem: Loga
- Payroll: Ja
- Hochrechnung: Ja
- Zeitwirtschaft: Nein
- HCM: Nein
- Stellenplan: Ja
- Auswertungsgenerator: Ja
- Analyse: Ja
- Archiv: Ja
- Sonstige: Loga@Mail
- Firma:
- Branche: ö.D.
Re: KK Stammdatenimport
Gerade mal getestet - den ASP (s.o.) habe ich angelegt und mit "Ja" gesteuert
Fussion (BKK RWE mit engergie-BKK zum 01.01.2022) in Krankenkassen-Import-Protokoll nach KK-Import vorgefunden. Automatische Vornahme der Fussion in LOGA = Fehlanzeige. Musste die üblichen Schritte (Anlage Empfänger/Adressen, Krankenkassen-Arbeitgeber für die bisher bei uns noch nicht vorhandene energie-BKK) vollziehen und natürlich im Krankenkassensatz BKK RWE unter "Fussion" die maschinelle Umsetzung anstoßen.
Der ASP fliegt bei mir jetzt wieder raus....
Ich denke grundsätzlich wäre hier eine Automatisierung tatsächlich möglich. Die Daten die im Datensatz Empfänger/Adressen zu hinterlegen sind (Adress- u. Bankverbindungsdaten) werden beim Import bereits mit gepflegt. Eigentlich müsste doch der Anwender höchstens noch nachsteuern müssen, falls er für die Fälle der Anwendung Umlage U1 (bzw. Pflichtigkeit hierzu) einen vom Standard abweichende Erstattungsregelung mit der jeweiligen Krankenkasse vereinbart. Na ja, vielleicht sehe ich das ja auch falsch bzw. übersehe noch etwas.
Fussion (BKK RWE mit engergie-BKK zum 01.01.2022) in Krankenkassen-Import-Protokoll nach KK-Import vorgefunden. Automatische Vornahme der Fussion in LOGA = Fehlanzeige. Musste die üblichen Schritte (Anlage Empfänger/Adressen, Krankenkassen-Arbeitgeber für die bisher bei uns noch nicht vorhandene energie-BKK) vollziehen und natürlich im Krankenkassensatz BKK RWE unter "Fussion" die maschinelle Umsetzung anstoßen.
Der ASP fliegt bei mir jetzt wieder raus....
Ich denke grundsätzlich wäre hier eine Automatisierung tatsächlich möglich. Die Daten die im Datensatz Empfänger/Adressen zu hinterlegen sind (Adress- u. Bankverbindungsdaten) werden beim Import bereits mit gepflegt. Eigentlich müsste doch der Anwender höchstens noch nachsteuern müssen, falls er für die Fälle der Anwendung Umlage U1 (bzw. Pflichtigkeit hierzu) einen vom Standard abweichende Erstattungsregelung mit der jeweiligen Krankenkasse vereinbart. Na ja, vielleicht sehe ich das ja auch falsch bzw. übersehe noch etwas.
-
- Beiträge: 575
- Registriert: 30.07.2008 09:31
- Abrechnungssystem: LOGA HR
- Payroll: Ja
- Hochrechnung: Nein
- Zeitwirtschaft: Nein
- HCM: Nein
- Stellenplan: Nein
- Auswertungsgenerator: Ja
- Analyse: Ja
- Archiv: Ja
- Firma:
- Branche:
- Kontaktdaten:
Re: KK Stammdatenimport
Hallo zusammen,
ja, die Fusion der BKK RWE mit der Energie BKK kam gerade auch bei mir hoch.
Es wird ja wirklich Zeit, den Unfug mit den zusätzlichen "Krankenkassen AG" und "Empfänger/Adressen" abzustellen. Eigentlich sollten doch alle erforderlichen Dateien für eine Krankenkasse in der Importdatei vorhanden sein.
Schöne Grüße
Christian Scho
ja, die Fusion der BKK RWE mit der Energie BKK kam gerade auch bei mir hoch.
Es wird ja wirklich Zeit, den Unfug mit den zusätzlichen "Krankenkassen AG" und "Empfänger/Adressen" abzustellen. Eigentlich sollten doch alle erforderlichen Dateien für eine Krankenkasse in der Importdatei vorhanden sein.
Schöne Grüße
Christian Scho
-
- Beiträge: 233
- Registriert: 30.01.2019 15:36
- Abrechnungssystem: LOGA HR
- Payroll: Ja
- Hochrechnung: Nein
- Zeitwirtschaft: Nein
- HCM: Nein
- Stellenplan: Nein
- Auswertungsgenerator: Ja
- Analyse: Ja
- Archiv: Ja
- Firma:
- Branche: Gesundheitswesen/Krankenhaus
Re: KK Stammdatenimport
Wir hatten jetzt erst bei der Fusion der BKK Energie das Thema, dass keine der Bankverbindungen die auf der Homepage der Krankenkasse standen, in Loga erfasst waren.
Aussage kurz und knapp laut P&I....Nicht Ihre Aufgabe....nur die Beitragssätze stellen die zur Verfügung...Klasse.... Macht dann total Sinn....Son Import!
LG
Bendrino
Aussage kurz und knapp laut P&I....Nicht Ihre Aufgabe....nur die Beitragssätze stellen die zur Verfügung...Klasse.... Macht dann total Sinn....Son Import!
LG
Bendrino
-
- Beiträge: 575
- Registriert: 30.07.2008 09:31
- Abrechnungssystem: LOGA HR
- Payroll: Ja
- Hochrechnung: Nein
- Zeitwirtschaft: Nein
- HCM: Nein
- Stellenplan: Nein
- Auswertungsgenerator: Ja
- Analyse: Ja
- Archiv: Ja
- Firma:
- Branche:
- Kontaktdaten:
Re: KK Stammdatenimport
Bei den Krankenkassen unter Import Bankverbindungen waren bei mir aber die richtigen Bankverbindungen der energie BKK enthalten.
-
- Beiträge: 139
- Registriert: 28.01.2013 13:51
- Hochrechnung: Nein
- Zeitwirtschaft: Nein
- HCM: Nein
- Stellenplan: Nein
- Auswertungsgenerator: Nein
- Analyse: Nein
- Archiv: Nein
- Firma:
- Branche:
Re: KK Stammdatenimport
Hallo zusammen,
nun, da es genügend kleinere Kunden/Mandanten (>=30 Mitarbeiter) gibt, welche U1-pflichtig sind, benötigt es eine Auswahl und zukünftige jährliche Pflegemöglichkeit, welcher der Parameter 1-3 (meist) vom Kunden/Mandanten gewünscht wird. Und diese Steuerung muss jährlich änderbar sein.
Also - nicht ganz so trivial m.E. wie von einigen Vorrednern beschrieben.
Grundsätzlich stimmt aber, dass ansonsten die Daten automatisiert kommen.
lg
admin1984
nun, da es genügend kleinere Kunden/Mandanten (>=30 Mitarbeiter) gibt, welche U1-pflichtig sind, benötigt es eine Auswahl und zukünftige jährliche Pflegemöglichkeit, welcher der Parameter 1-3 (meist) vom Kunden/Mandanten gewünscht wird. Und diese Steuerung muss jährlich änderbar sein.
Also - nicht ganz so trivial m.E. wie von einigen Vorrednern beschrieben.
Grundsätzlich stimmt aber, dass ansonsten die Daten automatisiert kommen.
lg
admin1984
-
- Beiträge: 575
- Registriert: 30.07.2008 09:31
- Abrechnungssystem: LOGA HR
- Payroll: Ja
- Hochrechnung: Nein
- Zeitwirtschaft: Nein
- HCM: Nein
- Stellenplan: Nein
- Auswertungsgenerator: Ja
- Analyse: Ja
- Archiv: Ja
- Firma:
- Branche:
- Kontaktdaten:
Re: KK Stammdatenimport
Krankenkassen AG, ok, wegen der Wahl des Umlagesatzes, aber Empfänger/Adressen müsste sich P&I doch eigentlich sparen können, oder?