Maximilian Stubhan
e30923e781
There was none anywhere in the model, so no personnel-cost figure could be produced at all, and an open position could not say whose budget it would charge — which is the first question asked about a vacancy. It hangs on the position, not on the person: the seat costs money even when nobody sits on it. That is exactly the vacancy case. And not on the org unit either, although it usually follows from one — a single seat can be charged elsewhere (project, shared function) without the unit moving. As its own dated assignment table rather than a column, because reassigning is an event with a date. Last year's costs have to stay where they were incurred; as a column, every change would silently rewrite every past report. Half-open [valid_from, valid_to), like position_assignments and om_positions — in SAP OM this is A011. 25 cost centres seeded from the org tree: one per company, division and department, with teams charging to their department, because a team is a span of control and not a budget. All 823 positions were assigned from their own start date, none left over. The number is the first five digits of the org number, so it can be traced rather than looked up. Reassignment refuses three things, each checked: the same cost centre again, a switch on the day the current one started (that period would never have been in force, and the range constraint says so), and a date before the position exists. Verified against the real data, which turned up a defect worth keeping: a position that starts in the future is charged only from its start, so asked about today it had no cost centre — and future positions are exactly what the vacancy list is for. It is now read at the position's own start date. Two audit entries from the probe could not be deleted through the application (the log has no delete policy — correctly), so I removed them with the admin connection. Still open, and the reason this is only the first of the three fields I proposed: location and planned FTE. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
77 lines
3.1 KiB
TypeScript
77 lines
3.1 KiB
TypeScript
import { describe, expect, it } from "vitest";
|
|
import { kontierungAm, kontierungZum, type KontierungsZeile } from "@/lib/cost-centers";
|
|
|
|
// Eine Umkontierung ist ein Ereignis mit Stichtag. Wer nach den Kosten des
|
|
// Vorjahres fragt, muss die Kostenstelle von damals bekommen — sonst
|
|
// verändert jede Umkontierung rückwirkend jede alte Auswertung.
|
|
|
|
function zeile(teil: Partial<KontierungsZeile>): KontierungsZeile {
|
|
return {
|
|
position_id: "p1",
|
|
cost_center_id: "k1",
|
|
code: "21010",
|
|
name: "Fertigung",
|
|
valid_from: "2020-01-01",
|
|
valid_to: null,
|
|
...teil,
|
|
};
|
|
}
|
|
|
|
describe("kontierungZum", () => {
|
|
const alt = zeile({ cost_center_id: "k1", code: "21010", valid_from: "2020-01-01", valid_to: "2026-09-01" });
|
|
const neu = zeile({ cost_center_id: "k2", code: "21090", name: "Qualitätssicherung", valid_from: "2026-09-01" });
|
|
|
|
it("liefert die Kostenstelle, die am Stichtag galt", () => {
|
|
expect(kontierungZum([alt, neu], "2026-08-31")?.get("p1")?.code).toBe("21010");
|
|
expect(kontierungZum([alt, neu], "2026-09-01")?.get("p1")?.code).toBe("21090");
|
|
});
|
|
|
|
it("behandelt den Zeitraum halboffen — der letzte Tag gehört der nächsten", () => {
|
|
// Sonst gälte am 01.09. beides, und welche Antwort käme, hinge an der
|
|
// Reihenfolge der Zeilen.
|
|
expect(kontierungZum([alt, neu], "2026-08-31").get("p1")?.code).toBe("21010");
|
|
expect(kontierungZum([neu, alt], "2026-09-01").get("p1")?.code).toBe("21090");
|
|
});
|
|
|
|
it("liefert vor Beginn der ersten Kontierung nichts", () => {
|
|
expect(kontierungZum([alt, neu], "2019-12-31").has("p1")).toBe(false);
|
|
});
|
|
|
|
it("liefert nach dem Ende der letzten nichts", () => {
|
|
const beendet = zeile({ valid_from: "2020-01-01", valid_to: "2024-01-01" });
|
|
expect(kontierungZum([beendet], "2024-01-01").has("p1")).toBe(false);
|
|
expect(kontierungZum([beendet], "2023-12-31").has("p1")).toBe(true);
|
|
});
|
|
|
|
it("hält mehrere Planstellen auseinander", () => {
|
|
const andere = zeile({ position_id: "p2", cost_center_id: "k3", code: "21030" });
|
|
const karte = kontierungZum([alt, neu, andere], "2026-09-01");
|
|
expect(karte.get("p1")?.code).toBe("21090");
|
|
expect(karte.get("p2")?.code).toBe("21030");
|
|
});
|
|
|
|
it("kommt mit einer leeren Liste zurecht", () => {
|
|
expect(kontierungZum([], "2026-09-01").size).toBe(0);
|
|
});
|
|
});
|
|
|
|
// Eine Planstelle, die erst entsteht, wird erst mit ihrem Beginn kontiert.
|
|
// Zu heute gefragt hätte sie keine Kostenstelle — und die Vakanzliste, die
|
|
// künftige Stellen bewusst zeigt, stünde für genau diese ohne da. Das ist beim
|
|
// Prüfen gegen die echten Daten aufgefallen, nicht beim Schreiben.
|
|
describe("kontierungAm", () => {
|
|
const kuenftig = zeile({ position_id: "p9", valid_from: "2027-01-01", code: "21030", name: "Logistik" });
|
|
|
|
it("liefert zum Beginn der Planstelle die Kostenstelle", () => {
|
|
expect(kontierungAm([kuenftig], "p9", "2027-01-01")?.code).toBe("21030");
|
|
});
|
|
|
|
it("liefert davor nichts — sie gilt ja noch nicht", () => {
|
|
expect(kontierungAm([kuenftig], "p9", "2026-08-16")).toBeNull();
|
|
});
|
|
|
|
it("verwechselt Planstellen nicht", () => {
|
|
expect(kontierungAm([kuenftig], "p1", "2027-01-01")).toBeNull();
|
|
});
|
|
});
|