Manager ID verweist ueber die Cornerstone-ID, nicht ueber die Personalnummer
All checks were successful
CI / Lint, Typen, Tests, Build (push) Successful in 11m53s
CI / Migrationen auf leerer Datenbank (push) Successful in 10m27s

Im Feld Manager stand die Personalnummer der vorgesetzten Person -- also der
Wert, der in derselben Zeile als Local System ID gefuehrt wird. Cornerstone
verknuepft aber ueber die User ID. Der Verweis lief damit entweder ins Leere
oder, schlimmer, auf jemand anderen, dessen User ID zufaellig aussieht wie
eine Personalnummer.

Leer, wenn die vorgesetzte Person selbst keine Cornerstone-ID traegt. Aus
demselben Grund wie bei User ID und Username: eine Kennung der falschen Art
ist schlimmer als keine, weil niemand ihr ansieht, dass sie falsch ist. Bei
435 von 785 Personen fehlt die Kennung noch -- das ist eine Luecke in der
Zuordnungstabelle, kein Fehler im Export.

Die Abbildung im Kontext heisst entsprechend managerKennung und traegt jetzt
Zeichenketten, damit der Typ selbst keine Nummer mehr zulaesst.
This commit is contained in:
2026-09-28 11:13:55 +02:00
parent 779beb4478
commit 677ca35df2
4 changed files with 42 additions and 14 deletions

View File

@@ -178,8 +178,8 @@ export type CornerstoneQuelle = {
};
export type CornerstoneKontext = {
/** Personalnummer je Mitarbeiterkennung — Cornerstone verweist über die User ID. */
managerNummer: Map<string, number>;
/** Cornerstone-ID je Mitarbeiterkennung — der Verweis auf die vorgesetzte Person. */
managerKennung: Map<string, string | null>;
/** Kostenstelle je Planstelle zum Stichtag. */
kostenstelle: Map<string, Kostenstelle>;
};
@@ -209,7 +209,16 @@ export function baueCornerstoneZeile(p: CornerstoneQuelle, k: CornerstoneKontext
const nummer = String(p.personnel_number);
const adName = benutzername(p.first_name, p.last_name);
const kst = p.position_id ? k.kostenstelle.get(p.position_id) : undefined;
const chef = p.manager_id ? k.managerNummer.get(p.manager_id) : undefined;
// Der Verweis auf die vorgesetzte Person geht über **deren** User ID, also
// über ihre Cornerstone-ID. Hier stand die Personalnummer: die ist in dieser
// Datei die Local System ID, und Cornerstone hätte den Verweis entweder ins
// Leere laufen lassen oder — schlimmer — auf jemand anderen gelegt, dessen
// User ID zufällig so aussieht wie eine Personalnummer.
//
// Leer, wenn die vorgesetzte Person selbst keine Cornerstone-ID trägt. Aus
// demselben Grund wie oben: eine Kennung der falschen Art ist schlimmer als
// keine, weil niemand ihr ansieht, dass sie falsch ist.
const chef = p.manager_id ? k.managerKennung.get(p.manager_id) : undefined;
const ausgetreten = p.status === "Ausgetreten";
return {
@@ -222,7 +231,7 @@ export function baueCornerstoneZeile(p: CornerstoneQuelle, k: CornerstoneKontext
Suffix: p.title_suffix.join(" "),
Username: kennung,
Approver: "",
Manager: chef ? String(chef) : "",
Manager: chef ?? "",
Absent: "",
"Allow Reconciliation": "",
Email: p.company_email ?? "",
@@ -274,6 +283,10 @@ export function baueCornerstoneZeile(p: CornerstoneQuelle, k: CornerstoneKontext
// Cornerstone-Position-ID. Sie hier einzutragen hiesse, eine Kennung des
// Zielsystems zu erfinden.
"Position ID": "",
// Der Hay-Grade, so wie er gespeichert ist. Wer keinen trägt, bekommt den
// „Generic Grade" — und der ist laut der Tabelle des Kunden der
// Bindestrich, nicht die leere Zelle. Hier wird deshalb nichts übersetzt;
// siehe lib/hay-grade.ts.
"Grade ID": p.paygrade,
"Cost Center ID": kst?.code ?? "",
// Leer: Cornerstone erwartet seine eigene Standortkennung („01"), und