Umstellung des Sollzeitsystems
Skalierung
Die Sollzeiten werden im neuen System pro Tag als Wochentag-Sollzeiten festgelegt. Sollzeit Werte für beliebige Perioden werden aufgrund der Tages Sollzeiten berechnet.
Die anderen Werte werden normalerweise für grössere Perioden (Monat, Jahr) festgelegt. Zur Umrechnung dieser Werte auf beliebige Zeitperioden oder Beschäftigungsgrade wird jeweils eine Skalierung angewendet.
Es gibt 2 Varianten von Skalierungen:
- Periodenskalierung: Berechnung eines Wertes für eine Teilperiode. Anwendung: z.B. Ferienguthaben bei Eintritt- oder Austritt während des Jahres, Gemeinkosten für eine bestimmte Periode.
- Sollzeitskalierung (Skalierung nach Beschäftigungsgrad): Hier wird ein Gruppen-Vorgabewert, welcher für 100% Beschäftigungsgrad gilt, für einen Mitarbeiter mit geringerem Beschäftigungsgrad umgerechnet. Diese Art der Skalierung geschieht über das Verhältnis der Sollzeiten von Gruppe und Mitarbeiter.
Im allgemeinen Fall werden beide Arten der Skalierung kombiniert, indem die Sollzeitskalierung für unterschiedliche Perioden für Gruppe und Bearbeiter berechnet wird.
Vergleich der Berechnungen altes und neues Sollzeitensytem
Die Unterschiede in den Berechnungen nach altem und neuem Sollzeitensystem sind hier nachfolgend erklärt.
Durch die Umstellung in der Skalierung gibt es teilweise kleinere Abweichungen zwischen altem und neuem System. Wie es dazu kommt, ist ebenfalls genau beschrieben.
Je grösser die berechnete Zeitperiode, desto höher wird in dem Fall auch die Wahrscheinlichkeit von Abweichungen zwischen altem und neuem System sein. Eine Möglichkeit, diese Abweichung möglichst klein zu halten, ist, die Konvertierung im frühen Januar durchzuführen. Dann ist die Zeitperiode, für welche Ferien- und Überzeitsaldi berechnet werden, minimal. Daher zeigen sich am wenigsten Unterschiede vom alten zum neuen System.
|
ALTES SYSTEM |
NEUES SYSTEM |
|
|
Periodenskalierung |
Nach Arbeitstagen (MO-FR). Ferien Oktober 2008 = 210 / 262 *23 =18.44h Nachteil: Schwer nachvollziehbar, da Anzahl Arbeitstage nicht einfach zu berechnen. |
Nach Kalendertagen.
Ferien Oktober 2008 = 210 / 366 * 31=17.79h Vorteil: Einfach nachvollziehbar. |
|
Sollzeitskalierung |
Zwei Varianten, je nach Systemeinstellung "Ferienberechnung aufgrund von Sollzeiten": Ja: Skalierung aufgrund von Sollzeitenverhältnis Bearbeiter / Gruppe. Wochenenden, Feiertage und Ferien beeinflussen die Skalierung. Nein: Skalierung aufgrund von Wochentags-Sollzeitenverhältnis Bearbeiter/Gruppe. Feiertage und Ferien haben keinen Einfluss, jedoch Wochenenden. |
Skalierung nach "Kalendersoll". Zur Berechnung des Kalendersoll Wertes für eine Periode wird mit gemittelten Tagessollzeiten (Wochensoll/7) gerechnet. Bei gleichen Sollzeit Vorgaben für Bearbeiter und Gruppe entspricht das der Skalierung nach Kalendertagen. Bei gleichen Perioden und konstanter Sollzeitvorgabe entspricht die Skalierung dem Verhältnis der Wochensollzeiten (Beschäftigungsgrad). |
|
Berücksichtigung von Minuten-Bruchteilen. Wirkt sich auf Sollzeitberechnung aus, falls Tagessollzeit Minutenbruchteile enthält. |
Sollzeit pro Tag ist auf ganze Minuten gerundet. Bsp: Wochensollzeit (Gruppe) 42:00. -> Tagessoll 504 Min. 80% -> Tagessoll 403.2
|
Sollzeitberechnung berücksichtigt Minutenbruchteile.
80% -> Tagessoll 403.2
|
|
OCL Operator |
Berücksichtigt keine fixierten Monats-Ferienwerte (grün) auf Bearbeiterjahren. Der Feriensaldo auf der Oberfläche (derived Attributes auf BearbeiterJahr und Projektbearbeiter) berücksichtigt die fixierten Monats-Ferienwerte. |
Berechnet den Ferienanspruch für eine bestimmte Periode. |
|
Berechnung Feriensaldo (derived Attribute, Saldo "per Gestern") |
Berücksichtigt Ferienbezug ink. heute. |
Berücksichtigt Ferienbezug bis und mit gestern. |
Umwandlung bestehender Daten
Hier finden Sie eine detaillierte Auflistung, wie die bestehenden Daten umgewandelt werden. Grundsätzlich gilt:
Einstellungen, die systemweit hinterlegt waren in der alten Version (z.B. Wochensollzeit, Ferien) sind nachher auf der Standard-Benutzergruppe hinterlegt.
Die Bearbeiter müssen in mindestens einer Gruppe mit Vorgaben sein, sonst haben sie keine Vorgaben.
Umwandlung fixierter Werte von Bearbeitern
Die fixierten Werte auf Bearbeitern im alten System sind die, die auf Ebene Bearbeiter überschrieben wurden und vom auf der Gruppe hinterlegten Standard abweichen. Sie erscheinen auf dem Bearbeiter in grüner Schrift.
Jeder dieser fixierten Werte wird übernommen. Deshalb kann es bei
der Umwandlung auf das neue System sein, dass sie bei gewissen
Mitarbeitern viele Vorgaben-Zeilen erhalten.
Alle Umwandlungen auf einen Blick
|
VORHER |
NACHHER |
|
Systemweite Arbeitszeit-Einstellung Wochensollzeit (Menü Optionen > Arbeitszeitvorgaben > Wochensollzeit) |
Sollzeit-Vorgabe per 1.1.1900 auf Standardgruppe. |
|
Systemweite Arbeitszeit-Einstellung Ferien (Menü Optionen > Arbeitszeitvorgaben > Ferien) |
Ferien-Vorgabe per 1.1.1900 auf Standardgruppe. |
|
Arbeitszeitvorgaben auf Benutzergruppe, |
Sollzeit-Vorgabe per 1.1.1900 auf entsprechender Benutzergruppe. |
|
Arbeitszeitvorgaben auf Benutzergruppe, |
Ferien-Vorgabe per 1.1.1900 auf entsprechender Benutzergruppe. |
|
Sollzeit pro Wochentag oder Wochensollzeit auf Bearbeiter (Reiter Einstellungen auf Bearbeiter) |
Sollzeit-Vorgabe per 1.1.1900 auf Bearbeiter |
|
Beschäftigungsgrad auf Bearbeiter (Reiter Einstellungen auf Bearbeiter) |
Sollzeit-Vorgabe per 1.1.1900 auf Bearbeiter. |
|
Ferien auf Bearbeiter (Reiter Einstellungen auf Bearbeiter > Arbeitszeiteinstellungen) |
Ferien-Vorgabe per 1.1.1900 auf Bearbeiter. |
|
Lohn, Gemeinkosten auf Bearbeiter (Reiter Einstellungen auf Bearbeiter) |
Lohn bzw. Gemeinkosten-Vorgabe (monatlich) per 1.1.1900 auf Bearbeiter. |
|
Ferien auf Bearbeiter (Reiter Einstellungen auf Bearbeiter > Jahreseinstellungen) |
Ferienvorgabe für 1.1 – 31.12. des Jahres auf Bearbeiter. Bei Eintritt oder Austritt während des Jahres wird der Wert auf einen Ganzjahres-Wert aufskaliert. |
|
Fixierte Monatswerte auf Jahreseinstellungen Bearbeiter (Wochensoll, Ferien, Lohn, Gemeinkosten in grüner Schrift auf Reiter Einstellungen auf Bearbeiter) |
Entsprechende Vorgabezeile auf Bearbeiter mit Periode 1.1. des Monats bis letzter Tag des Monats. |
|
Fixierte Monatswerte für Sollzeit in grüner Schrift auf Jahreseinstellungen Bearbeiter (Reiter Einstellungen auf Bearbeiter). Diese Werte beinhalten im alten System den Abzug von Feiertagen. Das muss für die Übernahme als Vorgabe im neuen System zurückgerechnet werden. |
Die fixierten Monatswerte beinhalten im alten System den Abzug von Feiertagen. Die Vorgaben im neuen System sind immer vor Abzug von Feiertagen. Beim Konvertieren von fixierten Monatswerden werden deshalb die die Feiertage im entsprechenden Monat anteilsmässig zu den Werten dazugezählt, damit die Berechnung nach neuem System nach Abzug der Feiertage wieder stimmt. |
|
Ferienvortrag, Überzeitvortrag auf Jahreseinstellungen Bearbeiter (Reiter Einstellungen auf Bearbeiter) gesetzt. |
Ferienvortrag bzw. Überzeitvortrag per 1.1. des Jahres auf Bearbeiter. |
|
Altes System hat Saldi immer seit Anfang Jahr berechnet. Wenn kein Ferien- bzw. Überzeitvortrag eingetragen war, galt per 01.01. ein Saldo von 0. |
Das neue System kann Saldi auch über Jahresgrenzen hinweg berechnen. Deshalb wird einmalig auf der Standardgruppe ein Ferienvortrag und Überzeitvortrag von 0 per 1.1. des aktuellen Jahres gesetzt. |
Rückwärtskompatibilität neues Sollzeit-System
Kundenspezifische Reports, Listeneinstellungen, ExpressionOrdner etc., die auf dem bisherigen System mit BearbeiterJahren basieren, laufen nach dem Update auf Version 5.4 nicht mehr.
Die Umstellung ist normalerweise relativ einfach und mit OCL Operatoren möglich. Zur Vereinfachung gibt es den OCL Operator bearbeiter->getJahre(von, bis). Dieser liefert eine Liste von berechneten (derived) BearbJahr Objekten zurück. Das sind die Nachfolgeobjekte von BearbeiterJahr. Sie sind nicht persistent (nicht in der Datenbank gespeichert) sondern werden vom OCL Operator berechnet.
Die BearbJahr Objekte haben Eigenschaften Soll1 - Soll12 und Ferien1 - Ferien12, welche die monatlichen Sollzeiten bzw. Ferienbezug angeben.
Die Anzahl der Jahresobjekte im Ergebnis von getJahre richtet sich nach dem Datumsintervall. Für ein Intervall, welches sich in einem Jahr befindet, gibt es nur 1 Objekt. Wenn das Intervall nicht das ganze Jahr umfasst, dann sind die Soll und Ferien Attribute zum Teil 0 oder enthalten nur einen Teil eines Monats.
Beispiel eines Excel-Reports
Vorher
Den meisten Fällen gemeinsam ist, dass aufgrund einer Jahresangabe zuerst ein Bearbeiterjahr beschafft wird:
Set BearbeiterJahr = Bearbeiter.Eval("jahre->select(jahr=" + CStr(Jahr) + ")->first")
Anschliessend werden verschiedene Werte ausgelesen und ins Excel geschrieben:
'Ueberzeitvortrag
Wrksheet.Cells(AktuelleZeile, 4).Value =
BearbeiterJahr.Eval("ueberzeitvortrag/60")
'Sollzeit Januar
Wrksheet.Cells(AktuelleZeile, 6).Value =
BearbeiterJahr.Eval("soll1/60")
'Sollzeit Februar
Wrksheet.Cells(AktuelleZeile, 7).Value =
BearbeiterJahr.Eval("soll2/60")
'Sollzeit März
Wrksheet.Cells(AktuelleZeile, 8).Value =
BearbeiterJahr.Eval("soll3/60")
'...etc
Nachher
'Bearbjahr mit getJahre OCL Operator
beschaffen
Set BearbeiterJahr = Bearbeiter.Eval("getJahre(encodedate(" &
cstr(jahr) & ",1,1), encodedate(" & cstr(jahr) & ",12,
31))->first")
'Ueberzeitvortrag
Wrksheet.Cells(AktuelleZeile, 4).Value =
Bearbeiter.Eval("getUeberzeitvortrag(encodedate(" & cstr(jahr)
& ", 1, 1))/60")
Sonst bleibt dann alles gleich:
'Sollzeit Januar
Wrksheet.Cells(AktuelleZeile, 6).Value =
BearbeiterJahr.Eval("soll1/60")
'Sollzeit Februar
Wrksheet.Cells(AktuelleZeile, 7).Value =
BearbeiterJahr.Eval("soll2/60")
'Sollzeit März
Wrksheet.Cells(AktuelleZeile, 8).Value =
BearbeiterJahr.Eval("soll3/60")
'...etc
Beispiel für Scripts
In Fällen, wo man in ein BearbeiterJahr Objekt schreibt, sollte stattdessen eine Vorgabe angelegt werden. Im Beispiel wird der Wert aus dem Excel ins Vertec geschrieben:
Vorher
Ferienanspruch für ein Jahr setzen (alte Methode mit Bearbeiterjahr)
BearbeiterJahr.Member("xferien") = 60 * WrkSheet.Cells(i, Ferien_Col)
Nachher
Neu mit Ferienvorgabe anlegen:
'Ferienanspruch per 1.1. Jahr setzen
'prüfen ob bereits Vorgabe besteht
set oVorgabe = Bearbeiter.Eval("vorgaben->select((datum=encodedate("
& cstr(jahr) & ",1,1)) and
(ferien.asstring<>''))->first")
if oVorgabe is nothing then
set oVorgabe =
Vertec.CreateObject("BearbeiterVorgabe")
oVorgabe.Member("bearbeiter") = Bearbeiter
oVorgabe.Member("datum") = DateSerial(jahr, 1,
1)
end if
oVorgabe.member("Ferien") = 60 * WrkSheet.Cells(i, Ferien_Col)
Beispiel für Listeneinstellungen
Als Beispiel werden einige Listeneinstellungen (Spalten auf einer Liste von Bearbeitern) "übersetzt":
|
|
ALT |
NEU |
|
Sollzeit Monat 1 des aktuellen Jahrs |
jahre->select(jahr = date.year)->first.soll1 |
getSollzeit(encodeDate(date.year, 1, 1), encodeDate(date.year,01,01).lastofmonth) |
|
Ferienguthaben für das aktuellen Jahr (ohne Vortrag) |
jahre->select(jahr = date.year)->first.ferien |
getFerienVorgabe(encodeDate(date.year,1,1), encodeDate(date.year,12,31)) |
|
Ferienvortrag Anfang des aktuellen Jahrs |
jahre->select(jahr = date.year)->first.ferienvortrag |
Dieses System hat komplett geändert. Da es nun zu jedem Zeitpunkt möglich ist, einen Ferienvortrag einzugeben, macht die Abfrage auf Anfangs Jahr nicht so viel Sinn. Man kann z.B. den letzten Ferienvortrag abrufen mit: getFerienVortrag(date) |
|
Ferienguthaben im Monat 3 des aktuellen Jahrs (Ferienguthaben + Ferienvortrag – bezogene Ferien) |
jahre->select(jahr = date.year)->first.ferienSaldo3 |
Ferienguthaben per Ende März des aktuellen Jahrs: getFeriensaldo(encodeDate(2008,03,31)) |
|
Gemeinkostenbeitrag für den Monat 1 des aktuellen Jahres |
jahre->select(jahr = date.year)->first.gemeinkosten1 |
getGemeinkosten(encodeDate(date.year, 1, 1), encodeDate(date.year,01,01).lastofmonth) |
|
Lohn |
jahre->select(jahr = date.year)->first.lohn1 |
getLohn(encodeDate(date.year, 1, 1), encodeDate(date.year,01,01).lastofmonth) |
Anmerkung
Das ganze Sollzeiten-System wurde komplett neu gestaltet. Wichtiger als das reine "Übersetzen" der einzelnen Expressions ist es, das neue System zu verstehen. Das meiste ist einfacher und durchsichtiger geworden, und oft machen die alten, starren Expressions keinen Sinn mehr, weil es neu eine elegantere Lösung gibt.
| erstellt: | 08.12.2008 |
|---|---|
| geändert: | 08.12.2008 |
