Erfahrungen mit Release 15.9. (mit oder ohne BIGDATA)

[kappelb]

Wir werden am Donnerstag Release 15.9. einspielen. Sollte es nicht klappen, werden wir zurück auf 15.6. gehen. Ich werde darüber berichten.
Ich bitte jeden, der seine Erfahrungen im Echtbetrieb damit gemacht hat, das hier zu dokumentieren, damit wir aus der "Ratephase" heraus kommen. Ich hoffe, das hilft allen weiter.
Grüße
Barbara Kappel

[Shorty2009]

Wir haben Loga 15.9 in einem parallelen Entwicklungssystem installiert und siehe da ... Lohnartensteuerung Basis und Deutschland sind weg.

So können wir natürlich nicht mit dem System arbeiten und werden daher die Version nicht Produktiv nehmen.

[kappelb]

Der erste Versuch das Release 15.9. mit dem Setup ist mir misslungen.
Die Dateien wurden verteilt, aber danach ging es nicht weiter.
Bei der Anforderung des Aktivierungscodes hat das Programm gesagt, dass wir einen gültigen Code hätten. Dann hat er - glaube ich - gefragt, ob wir einen neuen brauchen. Das habe ich mit "nein" beantwortet.
Ab da hat das Programm gesagt: Fehler bei Installation Activierungscode (-1)
Dann habe ich aus der Sicherung, die LOGA selbst anlegt, alle alten Daten zurückgeholt. Aber auch da ließ sich das Setup nicht neu starten.
Noch schreibe ich mir das Problem selbst zu.
Wir werden nun das exakte Verzeichnis aus der Sicherung zurückholen und es noch einmal versuchen.
Übrigens: man hatte uns zugesagt, dass wir BIGDATA kostenlos bekommen. Das wäre im Vertrag drin.

[kappelb]

Ich muss den Eintrag mit BIGDATA revidieren. Ich bekam gerade einen Anruf von einem Herrn von P&I. Meine Kollegen haben das falsch verstanden. Auch wir müssen BIGDATA bezahlen.

[kappelb]

Der Herr von P&I hat mir gesagt, da solle ich mich an die techn. Hotline wenden. Dort habe ich angerufen: "das ist die falsche Nummer, da haben die sicher in Wiesbaden alle Leitungen besetzt und es wird hierhin umgeleitet".
OK, dann habe ich ein Ticket geschrieben. Anhänge von den Fehlermeldungen dran.
Zur Sicherheit noch einmal die Hotline angerufen, das Problem geschildert, erwähnt, dass ich schon ein Ticket erstellt hätte und dass der Herr von P&I gesagt hätte, dass es wohl nur ein Wert sein sollte, den man zurücksetzen muss. Die wüssten schon Bescheid.
Nun warte ich.

[kappelb]

Um 9:37 Uhr hat sich unser techn. Berater per E-Mail gemeldet, und nach einigen Mails hin und her lief das Setup wieder.
Es waren falsche Registrierschlüssel aus der Datenbank zu entfernen.

[kappelb]

Nachdem nun 15.9. läuft, soll der Lohnartenabgleich durchgeführt werden.
Es soll angeblich gehen, ohne dass man BIGDATA kauft.
Trotz eingetragenem Oracle-Driver kriegen wir SQL-Fehler-Meldungen, die nicht näher beschrieben sind.
Die SQL-Sektion in der P2001.ini ist ausgefüllt (und wahrscheinlich auch richtig)
Der Proxy wurde auch eingetragen. Bei der BDURL hab ich https://bigdata.pi-ag.com reingeschrieben. Leider kein Erfolg.

Der Techniker hat gefragt, warum wir keinen Kundenberater eingeschaltet haben? Davon stand in den Release-Papieren nichts.

[britzhk]

Wir haben 15.9 (noch kein BIGDATA-Kunde ) in einem Testsystem eingepielt.
Der LA-Abgleich lief einmal erfolgreich (als TEST) durch, seitdem kommt die aussagekräftige Dialog-Meldung: Sonstiger Fehler, es ist ein Fehler aufgetreten.


Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.


Okt 22, 2015 3:36:48 PM com.piag.lasfp.report.ReportLasFP <init>
INFORMATION: ~~~ ReportLasFP ~~~
Okt 22, 2015 3:36:48 PM com.piag.lasfp.report.ReportLasFP <init>
INFORMATION: ini: C:\Windows\P2001.INI
Okt 22, 2015 3:36:48 PM com.piag.lasfp.report.ReportLasFP <init>
INFORMATION: db: null | l2001 | ********
Okt 22, 2015 3:36:48 PM com.piag.lasfp.report.ReportLasFP <init>
SCHWERWIEGEND: java.lang.NullPointerException

[kappelb]

Wir haben den Fehler in unserer JDBC-Eintragung ausfindig gemacht, die das Setup automatisch angelegt hatte

jdbc.url=jdbc:oracle:thin:@xxxxxxxx:1521:loga


Hinter dem loga war noch unsere Domain angelegt. Das haben wir entfernt
Danach flutschte der Lohnartenabgleich-Test

[kappelb]

So nun sollte es "echt" werden. Der Parameter wurde auf "J" gesetzt... und es geht nicht. Inzwischen wissen wir auch, dass wir es nicht ohne Consultant hätten machen dürfen. Es klang in der Anleitung doch so einfach.
Wir bekommen eine leere Seite mit P&I-Logo.... ohne Kommentar...

[Dirk Zimmat]

Moin moin ...

Da ich nicht sicher bin hier bezüglich einer Testumgebung alles richtig verstanden zu haben erlaube ich mir einen Hinweis.

Nach Gesprächen mit Consultants erhielt ich folgenden Hinweis:

Auf keinen Fall in einer Testumgebung einen echten Lohnartenabgleich fahren!!
Der Abgleich kann dann nicht mehr in der Echt-Umgebung wiederholt werden!!!

Mit einer Testumgebung könnte aber wohl der Lohnartenabgleich im Status TEST ausgeführt werden.


Gruß,

Dirk Zimmat

[kappelb]

Es wurde beschlossen, dass wir das jetzt durchziehen. Damit andere nicht auch durch das Tal der Tränen müssen, dokumentiere ich unsere Erfahrungen, denn das würde ich mir im Interesse aller auch von anderen wünschen.

Mein Kollege hat einen Fehler beim Aufruf der HTML-Seite festgestellt. Innere HTML-Elemente sind mit Gänsefüßchen statt Hochkommata programmiert.
Ob es der Fehler ist, wissen wir noch nicht.

[kappelb]

Problem war der gesteuerte Parameter
BDURL = https://bigdata.pi-ag.com
Nach dem Löschen funktionierte der Aufruf im Browser.

Nun kann man Lohnarten aufrufen. Bei der Bedienung ist zu sehen, dass sie sehr auf Mobilgeräte abgestimmt ist.

[kappelb]

Wir versuchen gerade zu klären, ob es stimmt, dass der Lohnarten-ECHT-Abgleich ein Zurückgehen auf 15.6 unmöglich macht.
In die Datenbank 15.9. wurden bis jetzt keine produktiven Daten eingetragen.
Diese Frage stellt sich momentan noch rein rhetorisch.

[Matthias Grimm]

Hallo Frau Kappel,

vielen Dank für die Dokumentation, ich finde es super, dass man hier zusätzliche Infos bekommt.

Wir haben gestern unser Testsystem auch umgestellt und haben dann versucht den Lohnartenabgleich Testweise zu erstellen.

In unserer P2001.ini hatten wir folgende Einträge:

jdbc.url=jdbc:oracle:thin:@SERVERNAME:PORT:DATENBANKNAME
jdbc.drivers=oracle.jdbc.driver.OracleDriver

Leider ist folgende Fehlermeldung gekommen:

Es ist ein SQL-Fehler aufgetreten.
Bitte prüfen Sie in der P2001.ini den Eintrag für jdbc in der Section [SQL]:
jdbc.url=...

Über den sqldeveloper können wir uns aber mit unseren string von oben durchaus auf die Datenbank verbinden.

Konnten Sie schon nach dem Test LA Abgleich auf die BIG Data zugreifen, oder musste dazu tatsächlich erst der (wohl irreversible?) Echt Abgleich erfolgen?

Vielen Dank für eine Information

viele grüße
matthias grimm

[SOL]

Hallo allerseits,
nachdem ich so viele PN bezgl. einer Alternative zu LOGA bekommen habe, schreibe ich hier auch noch was dazu. Ich habe mich mit Sage Personalwirtschaft beschäftigt und denke dass man damit eine 1:1 HR Lösung hat.
Zu dem ist der Zeitpunkt günstig. Sage bietet einen Wechselrabatt von bis zu 35% auf die Lizenzen an und das erste Jahr kostet keine Wartung. Wenn man in Betracht zieht, dass die Sage Lösung gleichwertigen Ersatz bietet und man die Rabatte sieht, denke ich schon, dass das eine gute Alternative ist.

Wer gern mehr wissen möchte, kann sich gerne mit mir via pn in Verbindung setzen.

Gruß SOL

[LK]

Wir haben Loga 15.9 in einem parallelen Entwicklungssystem installiert und siehe da ... Lohnartensteuerung Basis und Deutschland sind weg.

So können wir natürlich nicht mit dem System arbeiten und werden daher die Version nicht Produktiv nehmen.

Ja das können wir bestätigen, die Menüpunkte
- Lohnartensteuerung Basis und
- Lohnartensteuerung Deutschland
gibt's nicht mehr.

Stattdessen soll man angeblich alle Änderungen über den BIG-DATA-Browser für die Lohnartensteuerungsdaten in Wiesbaden machen und dann in den lokalen server importieren.

Mit anderen Worten:
Es gibt derzeit keine offizielle Software, mit der man die eigenen Lohnartensteuerungsdaten auf dem eigenen Server ändern kann.

Derzeit funktioniert (inoffiziell) noch die parallele Verwendung des 15.6 clients auf der 15.9 Datenbank
R:\SAVE_15.6.0.5\P2001\LOGA.EXE
(Fehlermeldung mit 'Ja' bestätigen!).

Fazit: Die eigenen Lohnartensteuerungsdaten sind eigentlich unerreichbar und der Ersatz über editierbare Daten aus Wiesbaden ist kein Ersatz, weil die Masse der Felder und der möglichen Einträge und überhaupt jegliche Übersicht völlig fehlen.

Wir bleiben aber bei 15.9., damit wir die Katastrophe früher bekommen ...

[Dirk Zimmat]

Moin moin ...

Nach meinen Infos aus einigen Gesprächen mit verschiedenen P&I-Mitarbeitern soll die bisherige Lohnartensteuerung im Dialog abgeklemmt sein. Dies wird hier ja auch inzwischen mehrfach bestätigt.

Nun sagen die gleichen Quellen, dass BigData mit 15.9 (und dann auch 16.0) die Lohnartensteuerung in der BigData ohne Kauf des BigData-Pakets möglich machen soll.

Hierzu sind nur 2 Schritte auszuführen:

Ersten
muss BigData über die Administration berechtigt werden und

Zweitens
muss der Lohnartenabgleich ausgeführt werden. (Dies meint nur den Abruf der entsprechenden Auswertung, die auch berechtigt sein muss). Eine Nachbearbeitung der Lohnarten muss nicht erfolgen, dies würde nur den kostenpflichtigen Funktionen der BigData dienen. Die Lohnarten würden weiterhin uneingeschränkt funktionieren.

Allerdings können Anpassungen von Lohnarten dann nur in der BigData vorgenommen werden. Nach dem Downlaod und Merge der LOA arbeit die Lohnart lokal wie eingestellt.

Kann dies inzwischen von Anwendern bestätigt werden?


mfg
Dirk Zimmat

[roltis]

Hallo zusammen,

das ist aber nur der erste Schritt.
Vermutlich sehr bald wird dann der Sack zugemacht!

Rolf

[Matthias Grimm]

Hallo,

Nun sagen die gleichen Quellen, dass BigData mit 15.9 (und dann auch 16.0) die Lohnartensteuerung in der BigData ohne Kauf des BigData-Pakets möglich machen soll.

Das habe ich so auch gehört, aber nicht schriftlich, die Frage warum ich denn dann BIG DATA kaufen soll, was sozusagen der Mehrwert ist, konnt mir leider keiner beantworten.

viele Grüße
mgrimm

[LK]

Allerdings können Anpassungen von Lohnarten dann nur in der BigData vorgenommen werden. Nach dem Downlaod und Merge der LOA arbeit die Lohnart lokal wie eingestellt.

Kann dies inzwischen von Anwendern bestätigt werden?

hier die ersten Schritte dazu:

BIG-Data (nach Tabellensteuerung) anclicken,
Menü geht im browser auf,
Lohnarten anclicken,
Lohnartengruppenmenü geht auf (10 Lohnartengruppen von P&I und die eigenen, nicht zugeordneten 11. Gruppe),
Lohnartengruppe anclicken (z.B. 'Nicht zugeordnet'),
eigene Lohnartennumern werden sichtbar,
Lohnartennummer anclicken,
Browsersteuerung 'Smarte Dinge' anclicken,
Menü geht auf,
'Bewertung' mit der Maus (gedrückt halten) auf Inst... neben der gewählten Lohnart ziehen,
Bewertungsfenster für diese Lohnart erscheint ('Bewertung hat keine Parameter'),
Bleistift anclicken,
Lohnartensteuerungsmaske geht auf,
Gültigkeitszeitraum zurechtclicken (mühsam, falls nicht unbegrenzt),
Lohnartensteuerungsfelder in 5 Feldgruppen bearbeiten:
- Faktor
- Ergebnis
- Bewertungslohnart
- Umrechnung
- Rundung
und dann speichern (in Wiesbaden).

Alles was an Lohnartensteuerungsfeldern nicht da ist, hat der Programmierer vergessen, man denke nur an Durchschnitte, Kumulationen, Execfunktionen und -parameter, Steuern und Sozialversicherung ...

Möchte man sich mit solchen Stammdaten in Wiesbaden die zu evtl. zu ändernde Lohnartensteuerung auf dem eigenen Server überschreiben?
Weiß man auch, ob dabei auch Steuerungsinformation nicht mit Leer überschrieben wird?

[euslughb]

Alles was an Lohnartensteuerungsfeldern nicht da ist, hat der Programmierer vergessen, man denke nur an Durchschnitte, Kumulationen, Execfunktionen und -parameter, Steuern und Sozialversicherung ...

Möchte man sich mit solchen Stammdaten in Wiesbaden die zu evtl. zu ändernde Lohnartensteuerung auf dem eigenen Server überschreiben?
Weiß man auch, ob dabei auch Steuerungsinformation nicht mit Leer überschrieben wird?

Ich glaube, das will man nicht wirklich wissen.....

Nachdem wir ein paar Schweizer abrechnen, müssen wir auch das Release 15.9 einspielen. Für die Schweiz ist jedes Release ein Pflichtrelease. Ich bin gerade mit Hilfe des Consulters dabei, die ganzen Lohnarteneinstellungen & Co in einem "menschenlesbarem Format zu sichern". Anscheinend kann man nachher nicht mal mehr die Kontierung einer Lohnart sehen bzw. ändern.

Mich würde es gerne mal interessieren, was ein Richter dazu sagt, wenn ein Verkäufer ein Produkt im nachhinein, einseitig so verändert, dass der Käufer das Produkt eigentlich gar nicht mehr verwenden kann. Desweiteren noch Geld verlangt, dass er es wie bisher weiterverwenden kann.
Ich bin zwar kein Jurist, aber meinem persönlichen privatem Rechtsempfinden nach, ist das eigentlich nicht möglich, was da P&I gerade macht bzw. versucht zu machen.

mfg
Harald Brucker

[roltis]

Hallo zusammen,

der für uns zuständige VB hat letzte Wochen zugegeben dass sie Vorgehensweise der P&I rechtlich nicht durchsetzbar ist.
Aber er hat die Anordnung von oben!!

Gruß Rolf

[lra-shk]

Hat sich denn überhaupt mal jemand versucht rechtlich zu wehren???

Wir haben einen Brief an der Vorstand geschrieben, mit einigen der großteils allgemein bekannten, unklaren und strittigen Fragen zum Thema BigData und HCM. Die Antworten waren zum großen Teil sehr unbefriedigend beantwortet und es war auch keine Einsicht oder Entgegenkommen seitens der P&I zu verzeichnen.

Das Motto heißt: Friss oder Stirb! Eine wirkliche Wahl gibt es einfach nicht!

Hat denn niemand einen juristischen Versuch unternommen?
Oder wenigstens einen Teilerfolg erziehlen können?
Wieso können die das so durchziehen wenn das ganze Vorgehen am Ende garnicht Rechtens sein könnte?

[LK]

Wir versuchen gerade zu klären, ob es stimmt, dass der Lohnarten-ECHT-Abgleich ein Zurückgehen auf 15.6 unmöglich macht.
In die Datenbank 15.9. wurden bis jetzt keine produktiven Daten eingetragen.
Diese Frage stellt sich momentan noch rein rhetorisch.

Auf jeden Fall gibt es durch den Lohnartenabgleich neue Felder, die dann mit den Ergebnissen des Abgleichs gefüllt werden.

Man versuche hierzu:

SELECT LA,
SEKID,
SEKLA,
SEKVER
FROM LOGA.L2001.LAS
where SEKID is not NULL
order by LA

[SOL]

Hallo allerseits,

Das Lustige ist ja, wenn man sich anschaut, was die PUI an die BD übeträgt, dann sind das nur sehr wenige Daten wie LA Nummer und ein, zwei weitere Werte. Wie soll man denn dann seine eigene Lohnart in der BD z.B. ändern, wenn man dort gar nicht sehen kann, wie sie im Moment gesteuert ist.
Herr Zimmat hat das im anderen Threat sehr schön beschrieben und die Erfahrung haben wir auch gemacht: Will man sehen wie einer nicht zugeordnete Lohnart parametrisiert ist, bekommt man die Meldung keine Parameter gefunden oder so ähnlich.

Das ist schon irgendwie dubios. Hat jemand da andere Erfahrungen?

Gruß SOL

[roltis]

Hallo zusammen,

ist das evtl. die "spezielle" Interpretation der P&I zum Thema Qualitätssicherung?


Gute Woche Rolf

[kappelb]

Als wir 15.9. eingespielt und auch den Echtabgleich durchgeführt hatten, wurde festgelegt, das wir doch weiter mit 15.6. arbeiten und die Version mit 15.9. wurde zum Testsystem.
Nach dem Einspielen der Updates für 15.9. ist kein Zugriff mehr auf BIGDATA möglich. Ein SQL-Fehler tritt auf, der sagt, dass eine Tabelle oder View LASBEH nicht existiert.
Wir setzen jetzt die Datenbank und das Programm auf den Stand von Gestern zurück.
Hat jemand den gleichen Fehler gehabt?
Grüße
B. Kappel

[britzhk]

Hallo Herr Kappel,

diesen Effekt haben wir auch, auch wenn der prod. LA-Abgleich nicht gefahren wurde.
Wir haben ein Ticket erstellt.

[Matthias Grimm]

Hallo,

da ich am Mittwoch in Stuttgart auf dem Jareswechselseminar war kann ich vielleicht ein bisschen zur Aufklärung beitragen, ich habe das so verstanden:

was die PUI an die BD übeträgt, dann sind das nur sehr wenige Daten wie LA Nummer und ein, zwei weitere Werte. Wie soll man denn dann seine eigene Lohnart in der BD z.B. ändern, wenn man dort gar nicht sehen kann, wie sie im Moment gesteuert ist.

Das scheint wie folgt zu funktionieren gemappt, oder "verheiratet" wie sich P&I ausdrückt, werden die LA lokal, d.h. die ganzen Big Data LA liegen loklal auf der Datenbank. Dann wird eine Art Fingerprint der LA erstellt und in BIG Data hochgeladen.

"Sehen" kann man die eigene LA steuerung tatsächlich bis jetzt nur über Scout, bzw direkt auf der Datenbank. In Zukunft soll es möglich sein seine ganze LA Steuerung - wenn man das will - per zip File in BIG DATA hochzuladen. Zu sehen in BIG DATA ist bis jetzt nur auf welcher Ebene die LA liegt und eben die Nummer (Bsp.: MANAK123).

Das ist laut P&I auch nicht

evtl. die "spezielle" Interpretation der P&I zum Thema Qualitätssicherung

sondern wird mit "den Datenschützern unter Ihnen" (also mit Kundenwunsch) erklärt.

Das ändern einer LA wurde bsphaft wie folgt erklärt:

1. ich weiss wie eine LA gesteuert ist
   wähle meine eigene LA in BIG DATA aus
   ändere hier historisch was ich ändern will
   lege das in den Einkaufskorb und lade es lokal auf meinen Rechner
   Spiele es per merge ein.

viele Grüße
mgrimm

[kappelb]

Danke für die Bestätigung des Fehlers durch Herrn Britz.

Ich frage mich, ob andere 15.9. einsetzen, wenn der Fehler noch nicht ausgebügelt wurde. Aber vielleicht verzichten die Anwender dort auf die "Vorteile" von BIGDATA.
Grüße
Barbara Kappel

[kappelb]

Es gibt aber Anwender, die die Tabelle LASBEH haben.
Ich werde P&I bitten, mir das SQL für die Tabelle zu schicken. Vielleicht reicht das ja, um den Fehler zu beseitigen.
Grüße

[kappelb]

1. Update lief nicht durch, weil die Log-Datei auf einen Pfad geschrieben werden wollte, der nicht unser Standard-Pfad in der P2001.ini war
Nun haben wir LASBEH.
2. OracleDriver-URL hatte noch den Namen der alten Datenbank drin.
Im Nachhinein betrachtet: banal. Hinterher fragt man sich warum, man nicht da zuerst gesucht hat. Jeder, der Software zum Laufen bringen muss, hat das sicher schon erlebt.
Bin gespannt, ob wir einen neuen Echtlohndatenabgleich machen können.
Der Techniker hat gesagt, mit meinem Problem wäre ich in guter Gesellschaft ;-)
Grüße
B. Kappel