Varial vwe Personalabrechnung

Hier können sich Anwender von Abrechnungsprogrammen anderer Anbieter austauschen. Egal ob Paisy, SAP, Varial etc.
Antworten
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Varial vwe Personalabrechnung

Beitrag von LK »

Wir arbeiten jetzt mit Varial vwe : Varial World Edition Personalabrechnung
Zuletzt geändert von LK am 01.02.2017 13:09, insgesamt 2-mal geändert.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe (2.50)

Beitrag von LK »

Varial vwe bietet einen Nummernkreis von 99000 Anwender-Lohnarten.
Dadurch ist es möglich, die Lohnarten neu und gut zu strukturieren; man hat dann immer noch genügend Lücken für zukünftige Erweiterungen.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe (2.50)

Beitrag von LK »

In Varial vwe ist es standardmäßig eingerichtet, auch den Folgemonat zugleich rechnerisch abzuarbeiten. Dieser Zeitraum der zukünftigen Abrechnungen kann sich auch auf mehrere Monate (theoretisch max. 2 Jahre) erstrecken, auf der Basis aller verfügbaren Stammdaten. Das ist recht praktisch, wenn man prüfen möchte, ob Lohnartenformeln funktionieren oder wenn man eine Auskunft über die Nettowirkung einer zukünftigen Gehaltsänderung geben möchte.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe (2.50)

Beitrag von LK »

Leider gibt es für Varial vwe kein allgemeingültiges Importprogramm zur Übernahme von Altdaten. Man kann jedoch mit Einschränkungen das Migrationsprogramm benutzen, welches für den Übergang von Varial Guide auf Varial vwe konzipiert wurde. Insbesondere bei der Sozialversicherung gibt's hier jedoch Hürden, die man bei einem allgemeingültigen Importprogramm nicht hätte. Hier wünschte man sich mehr Weltoffenheit von der varial world edition.
Auch auf den Einsatz von Excel zur Aufbereitung der Importdaten ist besser zu verzichten, um die Feldeigenschaften über den csv-Import gezielter erfüllen zu können. Hier wäre natürlich alternativ ein Excel-Importprogramm (xlsx statt csv) wesentlich prickelnder und übersichtlicher ...
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe (2.50)

Beitrag von LK »

In Varial ist es möglich, bei einer Lohnart (nahezu) beliebig viele Folgelohnarten einzurichten. Dies ermöglicht eine recht flexible Steuerung der Lohnarten insgesamt.

Dazu passend gibt es dann auch die wählbare Möglichkeit, dass eine Lohnart die empfangenen Werte zunächst alle vollständig verarbeitet / summiert, bevor die Berechnung weiterläuft ('nur einmalige Erzeugung erlaubt' als Option der Lohnart).
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe (2.50)

Beitrag von LK »

Jede Eingabe oder Änderung von Abrechnungsdaten wird in Varial sofort zur Berechnung eingereiht.
Das betrifft dann jeden einzelnen Überstunden-Eintrag, jede Änderung bei Mitarbeiter-Stammdaten, jeden Fehlzeit-Eintrag, jede Lohnarten-Änderung usw. Alles will sofort berechnet werden.

Allerdings ergibt sich dadurch das Problem, dass die gerade in Arbeit genommene Abrechnung für einen einzelnen Mitarbeiter (z. B. Überstunde, Pfändung oder ähnl.) nicht im Ergebnis betrachtet werden kann, wenn aus anderen Gründen (z. B. Krankenkassenupdate, Lohnartenänderung, ...) noch einige hundert andere Abrechnungen in der Schlange anstehen ...
Sinnvoller wäre hier eine automatische Reihenfolgenbeeinflussung, die für jeden Varial-Benutzer seine zuletzt bearbeitete Person sofort berechnet und die übrigen erst danach (also nicht FIFO, sondern LIFO).
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe (2.50)

Beitrag von LK »

Bei der Einrichtung der Lohnarten zeigt sich, dass Varial vwe nicht in der Lage ist, aufgelaufene Kalenderjahreswerte in der Lohnart zu ermitteln, lediglich der Druck in der Verdienstabrechnung kann auch Jahreswerte zeigen, aber mit denen kann man eben in der Lohnart selbst nicht rechnen. Dies ist aber notwendig, um z.B. Jahreszuschüsse oder ähnl. Größen beherrschen zu können.
Diese für ein Lohnprogramm doch recht peinliche Lücke wird nun für uns durch Sonderprogrammierung in Kürze geschlossen, einsetzbar dann ab nächster Version (2.55).
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe (2.50)

Beitrag von LK »

Wir vermissen die Funktion, bei der Weitergabe von Werten an eine Folgelohnart, das Vorzeichen drehen zu können.
Zwar kann man (z. B. in der empfangenden Lohnart) das Vorzeichen recht bequem umdrehen, aber wenn man aus mehreren abgebenden Lohnarten eine bestimmte Folgelohnart ansteuert und dabei für einige PLUS und für andere MINUS rechnen möchte, dann benötigt man eine Zwischenlohnart, um eben für nur einige das Vorzeichen drehen zu können.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe (2.50)

Beitrag von LK »

Auch vermissen wir eine Funktion zur Einschränkung der Weitergabe an Folgelohnarten: z.B. Weitergabe nur, wenn Betrag oder Menge nicht null oder nicht positiv oder nicht negativ.
Auf diese Weise würden sich etliche Folgeberechnungen einsparen lassen, falls statt aller Personen nur einige Personen betroffen sind.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe (2.50)

Beitrag von LK »

Die Jubiläumsfunktionen sind in Varial vwe noch verbesserungsbedürftig.
Es fehlt die Möglichkeit, in der Lohnart die Betriebszugehörigkeit als Zahl abfragen zu können.
Man kann aber durch das Setzen geeigneter Bedingungen indirekt zum Ziel kommen:
- falls Betriebszugehörigkeit in Monaten = 12 , dann ist Betrag = 1 ;
- falls Betriebszugehörigkeit in Monaten = 24 , dann ist Betrag = 2 ; usw.
Wir haben gerade ein 55-jähriges Firmenjubiläum gefeiert. Sicherheitshalber haben wir also nun über 60 Bedingungszeilen in der Lohnart ...
Schöner und berechnungs-schneller wäre es also, die Betriebszugehörigkeit (in Monaten und in Jahren !) monatsgenau (!) in der Lohnart abfragen zu können, um damit weiterzurechnen ...
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe (2.50)

Beitrag von LK »

Es fehlt auch eine Funktion, zum Übernehmen von Werten (Menge, Satz, Betrag) aus zuvor berechneten Lohnarten der gleichen Abrechnung. In manchen Fällen ist es eben klarer und richtiger, Werte 'von oben' zu holen, als Werte 'nach unten' weiterzugeben, gerade wenn in der abholenden Lohnart nur wenige Personen statt alle Personen gerechnet werden.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe (2.50)

Beitrag von LK »

Für die Buchungen der Lohnabrechnung gibt es
- einen gedruckten Buchungsbeleg,
- eine Übergabe-Standard-Schnittstellendatei,
- eine Übernahmemöglickeit in Varial vwe Rechnungswesen.
Die einrichtbaren Kontierungen haben das Problem, das nur Buchungen gegen ein einziges Lohnverrechnungskonto unterstützt werden; Buchungen mit davon abweichenden Gegenkonten werden also falsch interpretiert, so dass dann der Buchungsbeleg nahezu unbrauchbar wird.
Nur bei der Übernahme in das Varial vwe Rechnungswesen wird (angeblich) das Gegenkonto korrekt ausgewertet. Da muß man kreativ werden ...
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe (2.45, 2.50)

Beitrag von LK »

Wer die Varial vwe Software installiert bekommt, erhält dabei nicht nur die notwendigen systemseitigen Stammdatentabellen ausgefüllt, sondern auch einige Anwender-Daten-Tabellen.
Solche mitgelieferten Daten stören sehr den Aufbau der eigenen Daten. Insbesondere im Bereich der Lohnarten wirken die mitgelieferten Anwender-Lohnarten sehr störend.

Man stelle sich vor, man kauft ein neues Auto und bemerkt dann, daß im Kofferraum ein Sack Kartoffeln liegt, weil der Hersteller zeigen wollte, wozu der Kofferraum gut ist ...

Wir haben diese Erstinstallations-DB damals zweimal zurück gehen lassen, damit sie geleert wird; ein drittes mal haben wir uns erspart und die Kartoffeln selbst entsorgt.

Auch müssen die systemseitigen Stammdatentabellen auf das Startdatum der Datensätze hin überprüft werden, um den Import von eigenen Datem mit frühem Beginndatum zu gewährleisten.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe (2.50)

Beitrag von LK »

Bei jedem Personalabrechnungsprogramm gibt's irgendwann den Zeitpunkt, wo die Abrechnung als endgültig gekennzeichnet wird (Monatsabschluss, Journalisierung).
Bei der erstmaligen Journalisierung in Varial vwe gibt es eine unlogische Logik-Prüfung, die den Abrechnungsstart gefährden könnte. Bei der erstmaligen Journalisierung werden (Sozialversicherungs-)Stammdaten auch für alle jene Personen erwartet, die den Betrieb bereits verlassen hatten, die also keine Abrechnung mehr benötigen; ist das logisch?
Wir hatten aus dem Vorsystem alle Personen / Beschäftigungen übernommen, die das Vorsystem (13 Jahre LOGA) gespeichert hatte, damit wir wissen, wer schon'mal hier war.
Wer also sichergehen möchte, dass die Erstabrechnung mit Varial vwe tatsächlich technisch funktioniert, der muß mit einer Datenkopie auf der Testdatenbank unbedingt eine Journalisierung vornehmen, da erst bei der Journalisierung diese Fehlerprüfung erfolgt.
Einfacher wär's natürlich, die Prüfung würde programmtechnisch vorverlagert werden (bei jeder normalen Berechnung), aber das wär sicherlich zu einfach ...
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe (2.50)

Beitrag von LK »

Angenommen, eine Person verdient brutto 2.500 EURO-Stücke. Welches dieser Stücke ist lohnsteuerfrei, welches unterliegt dem höchsten Steuersatz? Da man die Geldstücke nicht unterscheiden kann, kann man diese Frage nicht beantworten. Selbst wenn man sie beantworten könnte, bringt die Antwort keinen Erkenntnisgewinn, denn das eine Euro-Stück wäre ohne die anderen Euro-Stücke anders zu besteuern.
Varial vwe meint hier Abhilfe geben zu können. Varial rechnet für jede (Brutto-)Lohnart sofort die Lohnsteuer und sonstigen Abzüge aus. Ist das gut? Bringt das 'was? Ist das logisch?
Auch hier braucht man wieder eine Abschalteinrichtung ...
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe (2.55)

Beitrag von LK »

Da man aus der Anwendung heraus eigentlich nie weiß, wann man denn eine neue Abrechnung erwarten kann (die Warteschlange also abgearbeitet wäre), ist eine automatisierte Anzeige hilfreich:
SELECT count(DESCRIPTION) FROM [vwe_Prod].[vwe_Prod].[QRTZ_JOB_DETAILS] zeigt die Länge der Warteschlange,
SELECT count(TRIGGER_NAME) FROM [vwe_Prod].[vwe_Prod].[QRTZ_FIRED_TRIGGERS] zeigt die Anzahl der konkret in Arbeit befindlichen Abrechnungen.
Sobald beide Werte auf 0 stehen, kann man eine sinnvolle Abrechnung anzeigen oder drucken lassen.

SELECT count([SCHED_NAME]) FROM [vwe_Prod].[vwe_Prod].[QRTZ_JOB_HISTORY] zeigt die Anzahl noch nicht gelöschter historischer Berechnungs-Log-Einträge. Das ist normalerweise uninteressant. Es ist aber dann ein Warnzeichen, wenn die Anzahl exponentiell wächst. Liegt die Zahl (plötzlich) bei über 1 Mio Zeilen, dann droht bei uns Systemstillstand (gestern/heute: 6,6 Mio Zeilen, Stillstand).

Ein solcher Systemstillstand kann behoben werden mit:
-- delete everything from 'CALCULATION' scheduler
-- delete all simple_triggers
DELETE FROM QRTZ_SIMPLE_TRIGGERS WHERE SCHED_NAME = 'CALCULATION';
-- delete all simprop_triggers
DELETE FROM QRTZ_SIMPROP_TRIGGERS WHERE SCHED_NAME = 'CALCULATION';
-- delete all cron_triggers
DELETE FROM QRTZ_CRON_TRIGGERS WHERE SCHED_NAME = 'CALCULATION';
-- delete all blob_triggers
DELETE FROM QRTZ_BLOB_TRIGGERS WHERE SCHED_NAME = 'CALCULATION';
-- delete all triggers
DELETE FROM QRTZ_TRIGGERS WHERE SCHED_NAME = 'CALCULATION';
-- delete all job_details
DELETE FROM QRTZ_JOB_DETAILS WHERE SCHED_NAME = 'CALCULATION';
-- delete all calendars
DELETE FROM QRTZ_CALENDARS WHERE SCHED_NAME = 'CALCULATION';
-- delete all paused_trigger_grps
DELETE FROM QRTZ_PAUSED_TRIGGER_GRPS WHERE SCHED_NAME = 'CALCULATION';
-- delete all job_history
DELETE FROM QRTZ_JOB_HISTORY WHERE SCHED_NAME = 'CALCULATION';
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Varial vwe kennt gut 50 verschiedene Fehlzeitarten für die Mitarbeiter. Das kann etwas verwirrend sein. Bei der Auswahl der für einen Mitarbeiter zutreffenden Fehlzeitart fehlt aber leider der allerwichtigste Hinweis: 'bezahlte' oder 'unbezahlte' Fehlzeit?!
Auch hier muß man etwas nachhelfen ...
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Für jeden Mitarbeiter muß ein Urlaubskonto eingerichtet werden. Das ist schon umständlich.
Man könnte ja programmtechnisch das Urlaubskonto generieren, wenn dem Mitarbeiter ein Arbeitszeitmodell erstmals zugeordnet wird.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Die Varial-Arbeitszeitmodelle sind in der Lage, jeden Wochentag einzeln zu rechnen.
Wochenmodelle mit Montag 8 Std., So. 4 Std. sind also kein Problem.

Leider gibts bei der Tabelle der Arbeitszeitmodelle das technische Problem, dass sich der gewählte Schlüsselbegriff (logischer Schlüssel) über die Oberfläche nicht mehr ändern läßt. Es kann dann unübersichtlich werden, wenn man nicht konsequent vorbaut.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Zu prüfen ist (einmalig) auch die Sortierfolge-Eigenschaft der Datenbank und der Tabellen darin:

"... schon vor einigen Jahren wurde die Sortierfolge von Varial bei Neuinstallationen auf Latin1_General_CS_AS festgelegt.
Einige wenige Partner stellen diese aber nach der Neuinstallation wegen eines Vorsystems auf Latin1_General_CI_AS um.
Das führte beim Releaseupdate 2.55 zu einem Abbruch der Installation."

"... wenn die Datenbank-Sortierfolge und die Sortierfolge der Tabellen in ihrem Fall auf Latin1_General_CI_AS steht, können Sie das lt. Varial auch so lassen."

Aaaah ja.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Das Individualprogramm 'Andrucksteuerungen im Verdienstnachweis' ist jetzt da (7.452 €).
hc_2021.jpg
hc_2021.jpg (31.27 KiB) 10028 mal betrachtet
Es ist ein fest programmierter verbesserter Verdienstnachweis. Jetzt haben wir deutlich mehr Platz für Text durch den Wegfall überflüssiger Spalten und durch die Einbindung der Lohnarten-Beschreibung (der originale Verdienstnachweis ist eigentlich unbrauchbar).

Der verbesserte Verdienstnachweis wirkt auch für den Korrekturverdienstnachweis (bei Rückrechnung).
hc_2020.jpg
hc_2020.jpg (34.75 KiB) 10028 mal betrachtet
Allerdings gibt's hier das Problem, daß in der Korrektur Zeilen drin stehen, die in der ersten Abrechnung nicht gedruckt wurden, so dass der Mitarbeiter entsprechend irritiert ist.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Das Individualprogramm 'Aufgelaufene Jahreswerte ermitteln in Wertarten' ist jetzt da (2.940 €).
Jetzt kann man tatsächlich aufgelaufene Monatssummen des Kalenderjahres in der Lohnart berechnen.
Das braucht eigentlich fast jeder Anwender!
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Das Individualprogramm 'Monatlicher Turnus ...' ist jetzt da (2.650 €). Jetzt können wir endlich einzelne Kalendermonate für eine eigenständig rechnende Lohnart sperren, dadurch werden die Berechnungen übersichtlicher.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Wenn eine einzelne Abrechnung einen Fehler erzeugt, wird dies auf der Oberfläche nicht dargestellt. Das ist ein Manko.
Abhilfe schafft hier eine automatisierte Anzeige, damit man weiß, dass man aktuell Abrechnungsfehler hat:
SELECT count(ObjectId) FROM [vwe_Prod].[vwe_Prod].[EXCEPTION_T] where Year(Objectts) >= 2017 /* bzw. Abrechnungsstartjahr */
Nun weiß man, das da 'was nicht stimmt, kann die Fehlermeldung und die Person erforschen und dann nach der Ursache fahnden.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Das Menü ist in Varial eine Mischung aus Tradition und Historie. Also nicht immer sinnvoll.
Da ist es gut zu wissen, daß man neben benutzer-individuellen Favoriten auch (für alle Benutzer gemeinsam) das Menu komplett überarbeiten kann.
Das geht zwar an vielen Stellen recht holprig und fehleranfällig (Abbruch = Speichern), bringt aber doch ein vernünftiges Ergebnis.
Dieses Menü sollte man sich dann aber auch ausdrucken, weil beim nächsten update durchaus mancher Menupunkt wieder verschoben sein kann ...

Zum Menu ist noch zu erwähnen, dass es keinen Menupunkt 'Monatsabschluss' gibt, weil ja alles irgendwie schon automatisch fertig wäre, aber man muß doch noch etliche Prüfschritte / Meldeschritte / Zahlungsschritte beachten, bevor man und nachdem man den Monat abschließt (journalisiert) und dann ist es besser, man baut sich einen eigenen Menupunkt 'Monatsabschluss' mit etlichen Unterpunkten zurecht. Das ist doch mal eine sinnvolle Aufgabe für den Consultant.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Wer unbedingt eine Netto-/Brutto-Hochrechnung braucht, sollte sich das zeigen lassen.
In der Hilfe findet man hierzu:
Kategorie
Wählen Sie aus, zu welcher Kategorie diese Anwender-Wertart gehört.
Wertarten für die Netto-/Bruttohochrechnung:
Nettobezug AG
Es handelt sich um ein laufendes Entgelt, bei dem der Arbeitgeber die Anteile des Arbeitnehmers zur Sozialversicherung übernimmt.
...
Von Steuer ist hier nichts zu lesen!
Auch muß man (was ja auch nicht in der Hilfe steht) die Reihenfolge der Lohnarten beachten, denn wegen der eigenwilligen systemseitigen Abrechnungstechnik muß eine Hochrechnung am Schluß erfolgen ...
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Wenn man die Buchung der Lohnabrechnung direkt mit Daten aus der Datenbank machen will, ergibt sich das Problem, daß offensichtlich keine spezielle Tabelle für die Buchungen existiert.
Man muß sich also wohl auf die direkte Abrechnungstabelle (vwe_Prod.vwe_Prod.Valueposition_t) und zugehörige Stammdatentabellen konzentrieren.
Es ergibt sich dabei das Problem, daß Rückrechnungen als vollständig eigene Berechnungen dargestellt werden. Im Monat Februar findet man daher in der Regel 3 Abrechnungen, eine für Januar, eine für Februar und eine für Januar aus dem Blickwinkel Februar, also eine Rückrechnung. Alle Werte werden tendenziell positiv dargestellt, so daß man nicht einfach nur addieren darf, wenn man den Februar buchen möchte, sondern man muß auch subtrahieren und ignorieren. Subtrahieren, um die Rückrechnungsunterschiede zu ermitteln und ignorieren, weil die Auszahlungsbeträge der Rückrechnung nicht existieren.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Die Rückrechnungsauslösung ist lückenhaft. Eine komplette Übersicht aller Fehler hierzu kann ich nicht liefern. Aber ein Beispiel von dieser Woche:
Eine Lohnart sollte geändert werden. Um die Änderungen besser überblicken zu können, wurde die Lohnart erst ab akt. Monatsbeginn geändert. Das Ergebnis schien richtig. Nun wurde die Lohnartsteuerung vom akt. Monat auf auf den Jahresbeginn vorgezogen, indem das Gültigkeitsdatum überschrieben wurde. Das funktioniert gut. Aber es folgte keine Rückrechnungsauslösung. Theoretisch hätte es für alle jene Mitarbeiter eine automatische Rückrechnung auf den Jahresbeginn geben müssen, die von dieser Lohnart betroffen sind (bei uns wären es ca. 20% der Mitarbeiter gewesen). Es gibt auch keine sinnvolle programmseitige Anzeige, wann 'was (rück-)gerechnet wird. Da in unserem Fall die automatische Rückrechnung auf den Jahresbeginn unterblieb, mußte eine manuelle Rückrechnung für alle Mitarbeiter vorgenommen werden.
Es gibt offenbar auch keine Übersicht, welche Auswirkungen eine (solche) Rückrechnung hat; man müßte sich die Abrechnung für jeden Mitarbeiter einzeln anzeigen lassen, auch einen Rückrechnungsbuchungsbeleg kann man nicht erzeugen.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Gibt's einen Unterschied zwischen 0 und 'nicht vorhanden'? Eigentlich schon, aber bei Varial wird das ignoriert.
In Varial vwe kann man z. B. Lohnfaktoren anlegen. Dies nutzen wir für personenbezognene Prozent-Zulagen, Stundensätze und ähnl. Besonderheiten.
Ein Lohnfaktor, der 'mal eingegeben wurde und verarbeitet wurde kann zwar geändert werden aber nicht mehr sinnvoll zeitlich begrenzt werden: Man muß, wenn der Lohnfaktor garnicht mehr gültig sein soll, diesen Lohnfaktor auf 0 ab Datum x setzen; man kann nicht den Lohnfaktor ab Datum x löschen !
Das bedeutet: Die Lohnart, die den Lohnfaktor definitionsgemäß verarbeitet, rechnet ab Datum x weiter mit Lohnfaktor 0. Könnte man den Lohnfaktor aber ab Datum x löschen, würde auch der Anstoss für die Verarbeitung der Lohnart entfallen können.
Die fehlende Funktion der historisch korrekten Löschung ('nicht vorhanden') führt also dazu, dass Lohnarten rechnen, obwohl sie vielleicht nicht rechnen sollten. Dies kann sich bei der Weitergabe von anderen Werten derselben Lohnart an Folgelohnarten durchaus als Problem / Logik-Fehler bemerkbar machen.
Also bitte bei der Programmierung umdenken: 0 ist kein Ersatz für 'nicht vorhanden'!
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Ich komme noch'mal auf die Tabelle vwe_Prod.VALUEPOSITION_T zurück.
Wenn man die Lohndaten über BI-Tools oder sonstwie flexibel auswerten möchte oder wenn man die Buchungssätze für die Fibu detailliert aus der vwe-Datenbank holen möchte, dann kommt man an dieser Tabelle nicht vorbei. Leider ist die nicht sehr sinnvoll aufgebaut (die ELAD in LOGA dagegen schon). Hierzu ein Beispiel:

SELECT cast(EFFECTIVEFROM as date) as EFFECTIVEFROM,
cast(EFFECTIVEUNTIL as date) as EFFECTIVEUNTIL,
cast(VALIDFROM as date) as VALIDFROM,
cast(VALIDUNTIL as date) as VALIDUNTIL,
RESULTS
FROM vwe_Prod.vwe_Prod.VALUEPOSITION_T
WHERE OIDEMPLOYEE = 475748119520896132 and VALUETYPENUMBER = 95650
ORDER BY VALIDFROM desc, EFFECTIVEFROM desc


ergibt folgende Daten:
hc_2467.jpg
hc_2467.jpg (248.1 KiB) 9483 mal betrachtet
Das sind die Daten, wie sie historisch auf der Abrechnung gedruckt wurden, aber nun nicht mehr stimmen müssen. Gemeint ist es wie folgt:
Die 35 € aus der letzten Zeile wurden in den beiden nachfolgenden Monaten bestätigt.
Die 7 € hingegen, die für März abgerechnet wurden, gelten nicht mehr; eine StornoZeile gibt's dafür nicht. Sie müssen mit den 28 € zu 21 € saldiert werden. Wer hätte das gedacht?
Man hat also "mit normalen Bordmitteln" keine Möglichkeit BI-Tools zu nutzen, denn Datenschnitte / Filter, Pivottabellen, Sortierungen können auf dieser Basis nicht funktionieren.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Heute haben wir die Kündigung unseres Softwarepflege- und Betreuungsvertrages zum Jahresende erhalten.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe (2.55)

Beitrag von LK »

LK hat geschrieben:Schöner und berechnungs-schneller wäre es also, die Betriebszugehörigkeit (in Monaten und in Jahren !) monatsgenau (!) in der Lohnart abfragen zu können, um damit weiterzurechnen ...
Dieser Wunsch kann nicht erfüllt werden:
>aufgrund ... der notwendigen Änderungen im System können wir Ihnen kein wirtschaftlich sinnvolles Angebot unterbreiten.<
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Das Geburtsdatum ist ein wichtiges Datum in den Stammdaten.
Ein Feld Todesdatum fehlt allerdings in den Stammdaten. Es gibt zwar für den Todesfall in den Bewegungsdaten (Austritt und Fehlzeit) eine Erfassungsmöglichkeit, aber diese Eingaben bewirken keine Aktualisierung der Stammdaten.
Es gibt also keine Möglichkeit, über die Stammdaten zu prüfen, ob ein (Ex-)Mitarbeiter verstorben ist. Also kann man bei Serienbriefen nicht sicher sein, dass die angeschriebenen Personen noch leben...
->
" wir müssen die Änderung vor dem Hintergrund der technischen Restriktionen bei der Erweiterung der Datenbank um zusätzliche Felder ablehnen."
Zuletzt geändert von LK am 26.06.2017 07:43, insgesamt 1-mal geändert.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Wie gut muß eine Software sich alte benutzte Daten merken?
Neben den Auskunftspflichten und Rechenschaftspflichten für Arbeitskräfte, Betriebsräte, Geschäftsführung, Wirtschaftsprüfer und Behörden hätte man als Anwender auch eine gewisse Sicherheit über die Daten. Daran hapert's aber.
http://konsilium.de/blog/2014/04/07/bi- ... risierung/
Bi-temporale Tabellen (vollständig historisierte Tabellen) enthalten neben den fachlichen Attributen immer technische („Transaction-Time“) und fachliche Gültigkeit („Valid-Time“). Da durch die zwei Zeitdimensionen alle Aspekte der Historisierung eines Objekts abgebildet werden, spricht man bei einer bi-temporalen Tabelle auch von vollständiger Historisierung.
Für viele Tabellen in Varial vwe gibt's die notwendigen Datums-Felder/spalten. Aber da, wo's ganz wichtig wird, nämlich bei den Lohnarten/Wertarten, da gibt's zwar die Spalten, aber es wird nichts sinnvolles hineingeschrieben.
Wenn man also eine Wertart ändert, dann kann man angeben, ab wann die Änderung gelten soll (gültig ab = Valid_from), z. B. seit dem konkreten vorletzten Monat. Da aber die betreffenden Felder für den tatsächlichen Benutzungszeitraum (wirksam ab = Effective_from) nicht verwendet werden und keine entsprechenden Datensätze geschrieben werden, kann nach der Änderung nicht festgestellt werden, mit welchen Einstellungen die letzten beiden Monate abgerechnet wurden. Diese fehlende Historisierung ist ein echter Mangel. Man kann also im Zweifel nicht 'mal schnell nachsehen, wie die Wertart zuvor eingerichtet war, das ist der absolute Horror für die/den Lohnarten-Verantwortliche/n; man überzeuge mich vom Gegenteil.
Abgesehen davon, ist dies ein echtes GOBD-Problem!!
Knott GmbH - Lutz Kretschmer
Volker Nölle
Beiträge: 569
Registriert: 03.05.2010 11:59
Wohnort: Frankfurt
Abrechnungssystem: LOGA
Payroll: Ja
Hochrechnung: Ja
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Ja
Auswertungsgenerator: Ja
Analyse: Ja
Archiv: Ja
Firma:
Branche:
Kontaktdaten:

Re: Varial vwe Personalabrechnung

Beitrag von Volker Nölle »

Danke für die vielen Hinweise zu VARIAL! Mich persönlich berstärkt es in meiner Entscheidung, im Jahre 2004 als Consultant, der vorher VARIAL betreut hat, zu LOGA zu wechseln. Dass man mit P&I nicht glücklich ist, kann ich als ehemaliger Mitarbeiter gut verstehen, aber dann wechseln Sie doch in ein Rechenzentrum - dann können Sie LOGA nutzen und sind weit entfernt von der P&I :D

Gruß
Volker Nölle
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung

Beitrag von LK »

Hallo Herr Nölle,

ich habe bisher kein Rechenzentrum gefunden, dass uns die direkte SQL-Auswertung (SSMS, powerpivot, Excel) von 12 Mio Datensätzen der Abrechnungstabelle auf eigener Datenbank anbieten könnte, weder für LOGA, noch für Varial.
Da bleib ich lieber bei meinem eigenen SQL-Server und lasse ihn rechnen und verwalten.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Es gibt in Varial vwe keine Auswertung für die Meldung zur Ausgleichsabgabe nach SGB ("Schwerbehindertenliste"). Klar, das wären ja immerhin 12 Monatszeilen mit ein paar wenigen Spaltenangaben, das ist natürlich für Varial zu umständlich zu programmieren!
Wer sich also eine Varial-Lizenz kauft, sollte vom Preis 5 € für einen Taschenrechner runterhandeln!

PS vom 28.2.2018:
1) Selbst unser Berater hat keine Auswertungsmöglichkeit gekannt!
2) Wir haben nun 2.60 im Einsatz. Habe dort recht versteckt einen csv-Export für IW-ELAN gefunden, nicht unter Auswertungen, sondern unter Firmenstammdaten.
Einen menschen-lesbaren Ausdruck sucht man aber weiter vergeblich.
Zuletzt geändert von LK am 28.02.2018 14:38, insgesamt 1-mal geändert.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.55)

Beitrag von LK »

Ich muss nochmal 'was schreiben zur Historisierung von Wertarten / Lohnarten, denn die ist eigentlich nicht vorhanden. Ich schreib's jetzt so, wie ich es verstehe, gründlich ausprobieren möchte ich das nicht!

Wenn man eine Wertart rückwirkend ändert, dann verschwindet die Information, wie zuvor die Steuerung der Wertart gestaltet war, wie also die letzten Abrechnungen produziert wurden.
Das liegt daran, dass die Historisierungsfelder (effective_from, effective_until) bei den Wertarten nicht gesetzt werden; alles passiert über die Gültigkeitseinstellung (valid_from, valid_until). Wenn man 'geschickt ist', macht man sich mit einem Klick die Abrechnung der letzten Jahre kaputt, denn niemand kann recherchieren, wie zuvor gerechnet wurde, ein Datensatz der nicht mehr da ist, statt nur nicht mehr benutzt zu werden und nicht mehr gültig zu sein ist ein echtes GOBD-Problem und ein Unternehmens-GAU, wenn's richtig kracht.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.60)

Beitrag von LK »

Abrechnungs-Stillstand

Rund 420 Abrechnungen sind fehlerfrei durchgelaufen, 4 Abrechnungen blieben stecken.
Der Server versucht immer wieder, diese 4 abzurechnen, kommt aber nicht an's Ziel.
Keine Problemmeldung auf der Oberfläche, keine Fehlermeldung beim Mitarbeiter.
Die Job-Hstory zeigt irre Aktivität, aber es gibt kein Ergebnis.

Die Lohnabrechnung kann erst fertiggestellt werden, wenn ALLE Mitarbeiter abgerechnet sind.


Fazit:

SQL-Log meldet zwischen zwei 'Log was backed up'-Meldungen:
"SQL Server detected a logical consistency-based I/O-error: falsche Prüfsumme ...
Fehler 824 Schweregrad 24 Status 2"

Da der Fehler eine Woche zu spät gesehen wurde und dann noch 1 Woche mit ergebnislosen Datenrettungsaktionen verging, war eine Rücksicherung notwendig. Folge sind Differenzen in den Abrechnungen.

Consultant:
"... nochmals betonen, dass die Varial-Anwendung nicht die Ursache für die fehlerhafte Datenbank ist. "
Zuletzt geändert von LK am 26.09.2018 13:15, insgesamt 1-mal geändert.
Knott GmbH - Lutz Kretschmer
Volker Nölle
Beiträge: 569
Registriert: 03.05.2010 11:59
Wohnort: Frankfurt
Abrechnungssystem: LOGA
Payroll: Ja
Hochrechnung: Ja
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Ja
Auswertungsgenerator: Ja
Analyse: Ja
Archiv: Ja
Firma:
Branche:
Kontaktdaten:

Re: Varial vwe Personalabrechnung

Beitrag von Volker Nölle »

Also doch wieder zurück zu LOGA? :wink:
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.60)

Beitrag von LK »

nein, kein LOGA mehr. Wir sind froh, der Enge des LOGA-Lohnartenrahmens und der BIG_DATA-Abgleicherei entkommen zu sein.
Aber sicher, man muß schon'mal eine Ersatzlösung suchen oder kennen.
Knott GmbH - Lutz Kretschmer
LK
Beiträge: 84
Registriert: 30.10.2015 12:51
Hochrechnung: Nein
Zeitwirtschaft: Nein
HCM: Nein
Stellenplan: Nein
Auswertungsgenerator: Nein
Analyse: Nein
Archiv: Nein
Firma:
Branche:

Re: Varial vwe Personalabrechnung (2.60)

Beitrag von LK »

Neues Datenbankproblem: 2 Mitarbeiter-Lohnabrechnungen bringen einen Fehlerhinweis, aber es können auch danach noch alle anderen gerechnet werden, der Rechner ist nicht tot.

SQL-Log : Dump mitten in der Berechnung, "using dbghelp.dll version 4.0.5 ...
... CPerIndexMetaQS:: Error/Abort - Index corruption ...
Fehler 8646, Schweregrad 21, Status 1 ...
Unable to find index entry in index ID 1, of table 1651549713 ... index is corrupt ..."

Wie gesagt, der Rechner rechnete munter weiter.

Rücksicherung um 2 Tage. Fast wären die Journalisierung und die Zahlungen wieder weg gewesen.
Knott GmbH - Lutz Kretschmer
Antworten