V70Datenmigration

Allgemeines - grober Ablauf

• Der Datentransfer von der bestehenden V6.x Alex DB in ein V7 Instanz erfolgt über eine Datei im XML Format.
• Mit einer ab V6.5.23 enthaltenen Funktion kann diese Migrationsdatei erstellt werden ("Export" -> "V7.0 Migrationsformat...").
  • erzeugte Dateien:
    • "EXPORT.axml_7"
      • enthält alle zu übernehmenden Stammdaten (auch Referenzwerte)
    • "EXPORT.axml_7.QAAccountView.axml_7"
      • enthält einen AccountView, der für die Qualitätssicherung verwendet werden kann
    • "EXPORT.axml_7.root.axml_7"
      • enthält alle am Systemparameter gesetzten Parametereinstellungen
    • "EXPORT.axml_7.Punched.exp"
      • enthält Stempelungen von Stempeluhr, nur bei autom. Zeiterfassung. Diese Datei muss beim Import beim config-File der V7-Datenbank liegen. config-File -> Rechtsklick -> "QA: Zeitstempel importieren"
    • "EXPORT.axml_7.ManualPostProcessing.csv"
      • enthält spezielle Anweisungen für händische Arbeiten, die nachträglich in der V7-Datenbank durchzuführen sind
• Der Import in V7 erfolgt mit "Bfx.Alex.QA.Client.exe". Dadurch werden die Pläne mit Status "Ist" und "Planung" in V7 automatisch durchgerechnet und je nach Konfiguration (Detail s.u.) wird auch ein Zeitkontovergleich durchgeführt.

Ablauf im Detail

Kundenmodul für V7 erstellen

Das Kundenmodul muss von V6.5 auf V7 konvertiert werden.

Dafür ENTWEDER

• einen kleinen Export aus der "Echtdatenbank" erstellen ( -> siehe auch Export Pläne schneller machen ),

ODER

• ein "Gesamt_ori.AXX_6_5" (oder "_.axx64") erzeugen, das später zur Wiederherstellung der original Berechnung verwendet wird.

In jedem Fall muss dafür gesorgt sein, dass vor dem AXML-Export die original Berechnungsmodule (und nur diese) in der Datenbank eingespielt sind.

Reihenfolge der nachfolgenden Punkte muss eingehalten werden!

in V6.5 vorbereiten

• Basis, Standard, Standard-AZG usw. falls vorhanden aktualisieren, damit aus diesen "Standard-Modulen" keine Fehler angezeigt werden (zB bei "Edit" -> "Procedures").
• Beim ALT-Modul (Datei->Stammdaten->TCXModule) private Prozeduren herausnehmen, wenn das Modul übernommen werden soll, was wiederum nur dann erforderlich sein sollte, wenn der Kunde noch keine Standard-Abrechnung hat.
  • Stammdaten neu laden
  • Berechnungsfehler im XML und im TCX ausbessern (mit XML beginnen)

• Optionen -> "Berechnung Groß- Kleinschreibung beachten"
  • Stammdaten neu laden
  • Berechnungsfehler im XML und im TCX ausbessern (mit XML beginnen)
  • Wenn beim Übersetzen keine Fehler mehr kommen, im TCX unter "Edit" -> "Procedures" nachschauen, ob Fehler("Error") drin sind. Gegebenenfalls nach der Prozedur im TCX und XML suchen und die Schreibweise (groß/klein) vereinheitlichen. Stammdaten neu laden ist zum Aktualisieren der Anzeige nötig. Erst fertig wenn überall "OK" steht.

• Kundenmodul(e) exportieren (.AXX_7)

in V7 nachbearbeiten

• immer mit letzter V7.8 arbeiten: [in neueren Versionen sind Migrationsdateien nicht mehr vorhanden]
• Vorbereitung: leere V7-DB erzeugen, mit letzter Version 7.8 einsteigen und alle benötigten Module importieren, inkl. des zuvor in V6.5 erzeugten Kundenmoduls; neues Config-File anpassen (Zeiterfassung?): ALEX-Config-File
  • ...\XTC\Computation\Standard_Migration.AXX_7 importieren (Sorgt dafür, dass der Import ohne Fehler durchläuft. Kann vor Auslieferung der DB wieder gelöscht werden.)
  • [Eventuell bekommt man Feher im Kundenmodul: "AccountType hat kein (setzbares) Attribut >accumulated<", dann accumulated="" rauslöschen]
• Order auf 10000 erhöhen
• bei allen kundenspezifischen CompCodes einfügen: employmentFactorPercentPropertyType="PropertyType::BESCH_GRAD_IN_PROZENT" (wird für Urlaubszubuchung benötigt)
• Der Zugriff auf berechnete Konten im TCX hat sich von V6.5 auf V7 geändert. Beispielsweise schreibt man in V6.5 "LEISTUNGSSTD()", in V7 "conto( LEISTUNGSSTD )". Achtung! Ein falscher Zugriff bringt erst zur Laufzeit (und nicht beim Übersetzten) einen Fehler.
  • Klassiker:

LEISTUNGSSTD() => conto( LEISTUNGSSTD )
LFD() => conto( LFD_GESAMT )
AUSBEZAHLT() => conto( AUSZ_GESAMT )
FIX() => conto( FIX_GESAMT )
ARBEITSZEIT() => conto( ARBEITSZEIT )
RBD_L() => conto( RBD_L_GESAMT )

• procComputeSchemaForUltimoPreMonth="" -> gibt es in V7 nicht mehr, also löschen
• Wenn in einer Prozedur mit "string param" auch das Schlüsselwort "local" vorkommt, dann muss "local" gelöscht werden ( => Workaround für BUG bei Übergabe von stringParams ).
• Was in V6.5 in den "Stammdaten"/"Planungscode Berechnungen" zu finden war, steht in V7 in der PropertyGroup "Standard-Upgrade" beim Planungscode, und kann bei Bedarf so freigeschaltet werden:

<change>
<PropertyGroup name="PlanSymbolComputingUpgrade" hide="" />
</change>

• Muss bei Zeiterfassung wie folgt im XML (Kundenmodul) freigeschaltet werden:

<change>
<PropertyGroup name="ZF" hide="FALSE" />

<AccountGroup name="7"	hide="FALSE" /> 
<AccountGroup name="7a"	hide="FALSE" /> 

<Schema hide="FALSE" name="ZF_K1" />
<Schema hide="FALSE" name="ZF_SP" />
<Schema hide="FALSE" name="ZF_FR" />
<Schema hide="FALSE" name="ZF_FS" />
</change>

• In manchen Fällen nötig für Urlaubskonsum auf abgeschlossenen Plänen:

procedure EntitlementConsumptionDuration param entitlementType, consumption
{
	if		self.ForDate < Date( 2010, 11, 1 ) //== "Abgeschlossen bis" laut V7-Export-Einstellung
		and	entitlementType.Name == "01"
	then
		return conto( ABW_URLAUB_STD )	// für abgeschlossene Pläne aus Migration
	endif
	return consumption
}

• das kundenspezifische "RootProperties"-Modul wird erst nach dem AXML-Export erstellt

Vorbereitung für Export in V6.5

Allgemein

• Mögliche Probleme mit Zeiterfassung sowie mit alten 6.5er Versionen beachten!
• optional: Migration zuerst mit kleiner DB (Export) ausprobieren
  • dabei darauf achten, dass das älteste Monat nie berechnet wird, weder in V6.5 noch in V7; gerade bei mehrmonatigem DRZ müssen genügend unberührte Vormonate vorhanden sein
    • siehe auch unten bei Hauptpunkt "Export in V6.5" - Unterpunkt "Datumsfelder setzen" !

V6.5 Module

• Original 6.5er Module aus erhaltener DB einspielen, falls diese seit Erhalt der DB verändert wurden.
  • "Basis"-Modul ist nur notwendig, um möglichen Abstürzen vorzubeugen... das Property "Abrechnungscode" (aus CPP-Code) benötigt die PropertyGroup "tarifvertragliche Einstellungen" (aus "Basis"-Modul)
• Optional "X:\TCX Module 6.5\Sonstige Module\V7Migration.axx_6_5" importieren und gewüschte Parameter setzen:
  • "V7: EinzelZE Benutzer mit Lesezugriff migrieren?" J/N-Parameter für Steuerung der Lese-/Schreibberechtigung (je Bereich)
  • "V7: KEINE QA Referenzwerte setzen?" J/N-Parameter
  • "V7: Personal NICHT exportieren?" J/N-Parameter
• ansonsten dürfen keine Module eingespielt werden!

Statustreppe

• Statustreppe kontrollieren
  • gleichen Status für alle Stationen je Monat herstellen, Pläne ggf. abschließen oder zurücksetzten

SQL-Skripts

• unsinnige Stationszuteilungen löschen => SQL-Skript1 => kann immer blind ausgeführt werden
• überlappende Stationszuteilungen finden und korrigieren => SQL-Skript2 => liegen diese außerhalb des Zeitbereiches der migriert wird, ist keine Korrektur notwendig
• nur für Sonderfälle (falls die QA-Referenz-Werte aus unerklärlichen Gründen nicht 'grün' sind):

X:\SQLScripts\Migration_Delete_DANPersonalParam_Contract-Params.sql

=Workaround für V6.5-Bug bei Parameter-Wert-Vererbung... Personal- und Vertrags-Ebene wurde quasi als gleichwertig angesehen - es wurde immer der zeitlich später gesetzte Parameterwert geliefert. In V7 wird richtigerweise immer bevorzugt der Wert von der Personal-Ebene geliefert. Falls ein Kunde schon mit Soll- und Bewertungsverträgen gearbeitet hat, darf man dieses SQL-Skript wahrscheinlich immer einspielen, sonst aber auf keinen Fall!

Stammdaten

• Anspruchsarten
  • "V7 Anspruchstyp":
    • "01" für Urlaub in Stunden
    • "02" für Urlaub in Tagen usw.
    • Wenn das Feld "V7 Anspruchstyp" leer bleibt, wird diese Anspruchsart nicht migriert.
  • "Zeitraum":
    • Eine Kennzeichnung "Arbeitsjahr", "Kalenderjahr" bzw. "Angepasst" ist hier beim Export nicht mehr erforderlich. In V7 sollte als entitlementPeriod "Angepasst" ausgewählt werden, da es damit die wenigsten QADifferenzen beim Urlaubsrest gibt. (Im Modul: entitlementperiod ="2")
  • "Standardwert":
    • Hier muss der gleiche Wert eingestellt werden wie in V7 bei diesem Anspruchstyp, bevorzugt 0.00, ansonsten sollte der Wert so gewählt werden, dass er beim meisten Personal zutrifft, (Wert gilt für Vollzeitkraft).
  • "Anspruch in V7 für Teilzeit aliquotieren?":
    • Normalerweise gilt bei Urlaub in Tagen -> NEIN; bei Urlaub in Stunden -> JA.
    • muss mit Einstellung in V7 bei diesem Anspruchstyp zusammenpassen.
  • nur für Deutschland:
    • letzte Version von Standard_D_Anspruch_TVOeD_V76.AXX_7 verwenden

• Allg. Planungscodes
  • "Kurzcode": betrifft nur autom.Zeiterfassung: Kurzcode darf nicht doppelt vergeben sein. (V7 ist hier übrigens eh case-sensitive.)
  • "V7Anspruchsart": Planungscodes, die man zum Konsumieren von Ansprüchen benötigt (Urlaub, PU usw.), müssen bearbeitet werden. Es ist das Feld "V7Anspruchsart" zu füllen. Kommen mehrere Ansprüche auf einen Planungscode muss mit Semikolon getrennt werden.
    • Bsp. (in echt ohne Anführungszeichen schreiben):
      • "entitlementDayPlanSymbol_02" wenn dieser Planungscode zum Abbau von "Urlaub in Tagen" benötigt wird
      • "entitlementDayPlanSymbol_02;entitlementDayPlanSymbol_01" wenn dieser Planungscode zum Abbau von "Urlaub in Tagen" + "Urlaub in Stunden" benötigt wird
  • "V7Zeitkonto": nichts reinschreiben
    • ( Muss und darf man nur dann einstellen, wenn man in V7 bei diesem Planungscode ein anderes Zusatzkonto hinterlegt haben will als in V65. Wird zur Zeit nur in einem Spezialfall benötigt, nämlich zur Richtigstellung der Anspruchsberechnung in V7. zB AKH Linz, Erholungsurlaub für Ärzteabrechnung: Es wurde in V7 ein zusätzliches berechnetes Konto "Url-Konsum-Ärzte" angelegt; der Name dieses Kontos wäre vorab im Feld "V7Zeitkonto" einzutragen. )

• Benutzer
  • Benutzer mit Username "MIGRATION" in Stammdaten anlegen, um die Funktion "Export" -> "V7.0 Migartionsformat" freizuschalten. Passwort nicht erforderlich, als Name "@@@" vergeben.

• Benutzer / Bereiche / Berufsgruppen / Stationen / Umschlüsselungen
  • ... die in der Bezeichnung mit "@@@" beginnen, werden nicht migriert. zB: "@@@Pflegebereich", "@@@Dipl. Personal" --> Beschreibung
  • Achtung: Bei Bereichen werden auch die zugehörigen Stationen nicht migriert.
  • Arbeitserleichterung durch SQL-Scripts möglich:
    • z.B.: update DANUser set Name = '@@@'; commit; (setzt die Bezeichnung aller Benutzer auf "@@@")

• Umschlüsselung
  • für Qualitätssicherung: Beim Export werden auch Referenzwerte weggeschrieben, vorbereitend für den Zeitkonto-Vergleich mit V7 QA Client. Es werden aber nur für jene Konten Referenzwerte gesetzt, die in einer Umschlüsselung enthalten sind. Es ist daher sinnvoll eine zusätzliche Umschlüssung, zB für Salden/Urlaub/Soll/Total/AZG-Fehler-Konten, anzulegen.(Z-Konto Umschl.-> QA, Text -> @@@)
  • V7AccountName muss in der Umschlüsselung hinterlegt werden, falls der Kontoname in V7 nicht so lautet wie in V6.5
    • Bsp.: Zeitkonto = "Resturlaub in Std." (Zeitkonto das beim Anspruch hinterlegt ist), Lohnart = egal, V7AccountName = "ENTITLEMENT_BALANCE_01" (in echt ohne Anführungszeichen schreiben)

• Stammdaten neu laden und ALEX neu öffnen

Export in V6.5

• "Export" -> "V7.0 Migrationsformat..."
• Datumsfelder setzen:
  • definiert die Status-Treppe für alle Planungseinheiten in V7
  • versiegelte Pläne können in V7 NICHT geöffnet werden und werden beim V7Import NICHT nachberechnet; dienen nur für Auswertungen u.ä.
  • abgeschlossene Pläne können in V7 geöffnet werden und werden beim V7Import NICHT nachberechnet
  • Pläne im "Ist" und "Planung" können in V7 geöffnet werden und werden beim V7Import nachberechnet
  • "Versiegelt bis"
    • Datum soll so spät als möglich gewählt werden, da die Pläne beim Exportieren ab diesem Datum (inkl. einem Vormonat) eingelesen und dabei nochmals durchgerechnet werden. Alte Pläne dürfen normalerweise nicht mit einer neuen Berechnung durchgerechnet werden.
  • "Versiegelt ab"
    • Monats- und Wochen-Zeitkontostände werden ab diesem Datum bis inkl. "Abgeschlossen bis" exportiert
    • Personal mit Autritt vor diesem Datum wird NICHT exportiert
  • "QA-Ref-Werte bis inkl."
    • Referenzwerte der Monats-Zeitkontostände werden immer von "Abgeschlossen bis" bis inkl. diesem Datum exportiert
• "Daten aus ALT-Modul exportieren"
  • anhacken, wenn auch Daten aus jenen Modulen exportiert werden sollen, die "private Prozeduren" gesetzt haben. Erforderlich, wenn zB Abrechungscodes, Konten, Parameter etc. für Ärzte im ALT-Modul definiert sind und diese auch in V7 noch benötigt werden.
• "Ansprüche auf Jahresersten zusammenfassen"
  • anhacken, wenn die Zubuchungen immer mit 1.1. eines Jahres erfolgen. Eventuell falsch angelegte Personal-Anspuchs-Sätze werden dadurch automatisch "richtig" gestellt, bevor der eigentliche Export startet. Die Änderung wird in der V65-Datenbank festgeschrieben.
    • Beispiel für Auswirkung:

Vorher:
1.1.2008 Anspruch: +40, Startkorrektur: +10
1.2.2008 Anspruch: +10, Startkorrektur: -20
Nachher:
1.1.2008 Anspruch: +50, Startkorrektur: -10

• Demo
  • Dient zur Erstellung von V7-Demo-Datenbanken, wobei Personaldaten (Zuname, Vorname, Kurzname und PNr) anonymisieren werden.
• Minimal
  • Es werden keine Monatspläne migriert. Als "Startdatum" für die Pläne in V7 wird das "Versiegelt bis"-Datum verwendet.
  • exportiert werden: Bereiche, Planungseinheiten, Berufsgruppen, Personal, Dienstgruppen, Kostenstellen, Benutzer, Qualifikationen, Quali-Kreise
  • nicht exportiert werden: Dienste, Planungscodes, Wochenzeitmodelle, Lohnarten, Umschlüsselungstabellen, Farbmarkierungen, Selbstbedienungsbenutzer, Kontostände, Monatspläne
• "PST-Parameter exportieren" -> immer anhacken

• OK klicken
• Pfad für AXML Datei angeben. OK -> Export startet... kann je nach Datenmenge auch einige Stunden laufen

Änderungen in V7-Datenbank vor Import

Systemeinstellungen

• "Sommerzeitumstellung berücksichtigen" laut alter Version auf "Ja" oder "Nein" setzen
  • alternativ im XML (alte Vorgehensweise): <property name="ComputeWithDaylightSavingTime" from="01.01.1900" to="01.01.2100" value="X" />
• "Tagesarten spezial" laut alter Version angelegen; alte Bezeichung war "Tage exta bewerten"
  • alternativ im XML (alte Vorgehensweise): <property name="SpecialDaykind" from="24.12.2011" to="24.12.2011" value="HALB" />
• "Anspruchsspezifikationen": Anspruchsarten je nach Bedarf anlegen.[ACHTUNG: Verlauf] Hinweis: Man kann eventuell stattdessen das Modul "Externe_Anspruchsverwaltung.AXX_7" (Pfad: X:\Alex 7.0\XTC\AddOns) verwenden.
  • alternativ im XML (alte Vorgehensweise): Die Anspruchsarten "Urlaub in Tagen" und "Urlaub in Stunden" werden vom Modul "Standard Anspruch" zur Verfügung gestellt. Zur Aktivierung sind Anpassungen im Kundenmodul erforderlich -> siehe Aktivieren einer Anspruchsart
• bei auto. Zeiterfassung:
  • Systemeinstellungen -> "Zeiterfassung/Stempeluhr" -> "Auto-Zeitstempel erst ab 'Morgen 0:00' ermöglichen" auf 'JA' setzen
    • ist zumindest für einen korrekten Vergleich der QA-Ref-Werte notwendig!

"RootProperties"-Modul für V7 erstellen

• X:\Templates\KUNDE_RootProperties.AXX_7 in V7-DB importieren
• XML ändern:
  • Beim AXML-Export wird unter anderem eine ".root.axml_7"-Datei erzeugt. Den Inhalt dieser Datei im XML einfügen.
    • es muss immer die zuletzt erzeugte ".root.axml_7"-Datei verwendet werden, für den Fall dass sich Einstellungen am Systemparameter geändert haben
  • Prüfen, ob "EmployeeCompCode" mindestens einmal vorkommt. Hinweis: value="" heißt "Standardabrechnung", value="_X" heißt "Standardabrechnung unbew."
    • Kopiervorlage, falls "EmployeeCompCode" noch nicht vorkommt: <property name="EmployeeCompCode" from="01.01.1900" to="01.01.2100" value="" />
  • "DRZ_DAUER" u.ä. checken -> mögliche Fehlerquellen...
• alle Änderungen im XML dokumentieren
• das neue Modul in den Kunden-Ordner exportieren (Achtung: nicht das Template überschreiben)

Korrektur AXML vor Import

• Besonderheit Sollberechnungsverträge:
  • Da in V6 und V7 verschiedene Bezeichnungen für den Sollvertrag "15%_40h_7d", "25%_40h_5d", "37.5%_40h_5d", "95%_40h_5d" verwendet werden, müssen im axml diese Namen durch den in V7 verwendeten Namen "15%_6h_7d", "25%_10h_5d", "37.5%_15h_5d", "95%_38h_5d" ersetzt werden. Andere Standard-Sollverträge können auch betroffen sein, wir wissen aber nicht genau welche.
  • SQL-Skript zum Nachschauen, ob der genannte Vertrag überhaupt in der V6-Datenbank vorkommt:
    • select * from DANStationPersonal where TargetContract like '25%_40h_5d%'

Import in V7 mit Bfx.Alex.QA.Client.exe

• Mongo-DB:
  • DB- und Config-File von \\nas\bfx\dropbox\AlexExe\Alex 7.0\XTC\Templates herkopieren

• SQL-Server [OBSOLET]
  • DB selbst im Management-Studio erzeugen:
    • Wiederherstellungsmodell NACH Anlage der neuen DB unter "Eigenschaften" auf "Einfach" umstellen
    • Option "IsReadCommitedSnapshotOn" interaktiv im Management-Studio unter "Facets" auf "True" setzen (falls das nicht funktioniert 'hier' nachsehen)
    • anschließend DB booten über Contextmenü

• Bfx.Alex.QA.Client.exe wird über das Contextmenü des Config-Files angesteuert (Menü sollte selbsterklärend sein)

Nachträgliche Arbeiten in V7

• Planungscodes: TZMod-Check aus V6.5 wird NICHT automatisch übernommen und muss neu eingestellt werden
• Aufnahmetage: sind bei Linzer Krankenhäuser zu hinterlegen
• Systemeinstellungen: Namen für System hinterlegen
  • LIZENZ einstellen
    • Kontrolle mit "Anzahl Stammzugeteilte" ob Lizenz ausreichend ist!

• optional: V7-Modul für Summenansicht "Qualitätssicherung" erstellen
  • Beim Export wird eine "QAAccountView.axml_7"-Datei erzeugt. Der Inhalt der Datei muss im neuen Modul im XML eingefügt werden.

• ManualPostProcessing.csv durcharbeiten:
  • Da bei untermonatigen Stationswechsel die Zeitkontowerte für Monat nicht richtig exportiert werden können, wird das betroffene Personal im File aufgelistet. Bei diesen Personen muss man ab dem Datum, das im File angegeben ist, "Summen neu berechnen", um richtige Wert auf den V7Plänen zu erhalten. Die Korrektur erfolgt ab besten am Jahresplan. Ab dem erwähnten Datum werden für das Personal keine QAAccountReferences gesetzt.
    • Wenn das "Problem-Monat" noch vor dem letzten abgeschlossenen Plan liegt, sind für die Folgepläne keine Folgefehler (Saldoübertrag) zu befürchten; ein Nachberechnen ist dann eventuell nicht erforderlich, weil die Summen dann nur für das eine Monat, das schon abgeschlossen oder versiegelt ist, falsch sind.
    • Man kann im Excel nach der Datum-Spalte oder nach Berufsgruppe sortieren, um die relevanten Pläne herauszufiltern.
  • Personal mit Eintritt oder Austritt im Anspruchsjahr wird aufgelistet, da bei diesen die Anspruchs-Extras nicht gesetzt werden können. Es werden keine QAAccountReferences für "Entitlement-Konten" bei diesen Personen gesetzt.

• QA-Log-File durcharbeiten:
  • Schlagwörter für Suche (wichtig bei großem File):
    • <ERROR>_
      • kennzeichnet Systemfehler
      • z.B.: Dienstüberschneidung wegen gleicher Order
    • ERROR
      • kennzeichnet Unterschiede bei Zeitkontowerten
    • Fehler
      • z.B.: "Fehler >!HasEndOfRequestFromServer< aufgetreten"
    • Fehlerhafter Zeitstempel
      • kennzeichnet einen Fehler in der Zeitstempelverarbeitung -> kann man meist schon in V6.5 korrigieren
    • Zeitüberschneidung
      • kennzeichnet eine Dienstüberschneidungen -> kann man meist schon in V6.5 korrigieren
    • kann nicht aufgelöst werden
      • kennzeichnet einen Laufzeitfehler im XTC -> Plan öffnen und Berechnung anstoßen...

• mit aktuellster Version einsteigen (V2015/V2016)
• Kontrolle der Module -> Module löschen die zu löschen sind
• Passwort für Supervisor hinterlegen

mögliche Fehlerquellen:

• Falsche Ref-Werte: Falls bei Erstellung des AXMLs ein Plan in V6.5 im IST ist, in V7 jedoch in PLANUNG, so sind die hinterlegten Referenzwerte nicht korrekt!! Lösungsansatz: Plan bereits in V6.5. zurücksetzen und speichern.
• Verwendung von der Funktion "param_age": bringt in V7 ein anderes Ergebnis als in V6.5, wenn der abgefragte Parameter zweimal oder mehrmals in Folge auf den gleichen Wert gesetzt wurde.
  • bei Standardabrechnung wird diese Funktion bei den Parameter DRZ_DAUER, TZ_DRZ_DAUER, AZG_WOCHE_DURCH_ZEITRAUM und AZG_WOCHE_FREIE_WE angewendet.
  • bei alten Abrechnungen kann der Parameter "BEGINN_DRZ" betroffen sein
• Bekannte Kompatibilitätsprobleme im TCX, V6.5 -> V7

Probleme bei Zeiterfassung

• Kunden hat eine Versionen älter als 6.5.27.23 im Einsatz:

-> solche Migrationen mit Entwicklungsabteilung besprechen!

Es kann sein, dass in der alten Version ein falscher Lesemechanismus verwendet worden ist.

Ab 6.5.27.23 also auch in V7 wird ein richtiger Lesemechanismus verwendet -> d.h. es wird eine andere "Kartennummer" ausgelesen als zuvor.

• Kunde hat irgendeine V6.5 und den Systemparameter "Erweiterten Stempelzuordnungsmechanismus verwenden?" (ab 6.5.22.26 verfügbar) gesetzt:

-> bitte ebenfalls mit Entwicklungsabteilung besprechen!

Probleme bei Versionen älter als 6.5

• Bool-Properties:
  • können unerwartete Werte wie '1.0', '0.0' oder 'xy123' enthalten
  • Welche Properties betroffen sind, kann man mit einer "Minimal"-Migration herausfinden. Eine "Minimal"-Migration läuft schnell durch, da nur Stammdaten (inkl. Parameter) migriert werden. V7-Import wirft ggf. einen Fehler aus!
  • Achtung! Korrektur-Anleitung könnte noch feherhaft sein, sollte aber vom Ablauf grundsätzlich ok sein!
    • Korrektur erfolgt mit SQL-Scripts, Bsp.: "EVANGELISCH"-Property, X:\SQLScripts\Upgrade_V6.3_V6.5_V7_EVANGELISCH_korrigieren.sql
    • Korrektur muss schon in V6.5 vor dem Export erfolgen, damit
      • sich beim Exportieren keine Zeitkontowerte ändern (V6.5 soll sich verhalten wie V6.3)
      • im AXML-File als Wert nur "" oder "X" vorkommt
• Änderung der Tagesart für einzelne Tage:
  • Das war in alter Version mögich, ist aber ab V6.5 (also auch in V7) nicht mehr möglich. Ersatz kann durch Planungscode oder Sonderabrechnung geschaffen werden

Archiv vereinzelt aufgetretener Probleme

Dienste, deren ID sich nur durch Groß-/Kleinschreibung unterscheidet

• Wenn sich in solchen oder ähnlichen Fällen die 'Sortierung' der V6.5-DB ändert (zB von case-sensitiv auf case-insensitiv) kann das zu Problemen führen. Ist einmal aufgetreten bei einer SQL Server DB. Die Datenbankeigenschaft 'Collation Sequence'(='Sortierung') der V6.5 Datenbank hat sich beim Restoren oder Anhängen verändert. Mittels SQL Script ( alter database [DB_NAME] collate [SORTIERUNG] ) kann wieder die original Sortierung - diese wäre beim Kunden zu erfragen - eingestellt werden; dies müsste gemacht werden bevor man mit den üblichen Migrationsschritten startet.