Files
alpenwerk-hr/lib/cost-centers.ts
Maximilian Stubhan e30923e781 Give a position a cost centre
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>
2026-08-16 19:57:09 +02:00

108 lines
3.9 KiB
TypeScript

import type { Tx } from "./db";
import { jsonArrayFrom } from "./db/json";
import { todayIso } from "./format";
import type { OrgEb } from "./org";
// Die Kostenstelle einer Planstelle — zum Stichtag, nicht „aktuell".
//
// Sie hängt an der Planstelle, nicht an der Person: der Sitz kostet Geld, auch
// wenn niemand darauf sitzt. Genau das ist die Frage bei einer Vakanz.
//
// Und sie hat einen Zeitraum, weil eine Umkontierung ein Ereignis mit Stichtag
// ist. Wer nach den Kosten des Vorjahres fragt, muss die Kostenstelle von
// damals bekommen — sonst verändert jede Umkontierung rückwirkend jede alte
// Auswertung, und das merkt niemand.
export type Kostenstelle = {
id: string;
code: string;
name: string;
};
export type KontierungsZeile = {
position_id: string;
cost_center_id: string;
code: string;
name: string;
valid_from: string;
valid_to: string | null;
};
/**
* Die Kontierungen als *Teilabfrage* — zum Einhängen in die eine Abfrage, die
* eine Seite ohnehin stellt (lib/db/json.ts).
*
* Ohne `positionIds` alle. Gefiltert wird nicht nach Stichtag: die Auswahl
* trifft `kontierungZum` im Speicher, damit dieselben Zeilen für mehrere
* Stichtage reichen und die Abfrage eine bleibt.
*/
export function kontierungenAbfrage(eb: OrgEb, positionIds?: string[]) {
const q = eb
.selectFrom("position_cost_centers as z")
.innerJoin("cost_centers as k", "k.id", "z.cost_center_id")
.select(["z.position_id", "z.cost_center_id", "k.code", "k.name", "z.valid_from", "z.valid_to"])
.orderBy("z.position_id")
.orderBy("z.valid_from");
return positionIds ? q.where("z.position_id", "in", positionIds) : q;
}
/** Alle Kostenstellen zur Auswahl — abgelaufene bleiben draussen. */
export function kostenstellenAbfrage(eb: OrgEb, asOf: string = todayIso()) {
return eb
.selectFrom("cost_centers")
.select(["id", "code", "name"])
.where((e) => e.or([e("valid_to", "is", null), e("valid_to", ">", asOf)]))
.orderBy("code");
}
/**
* Welche Kostenstelle je Planstelle am Stichtag galt.
*
* Halboffen [valid_from, valid_to): der letzte Tag gehört schon zur nächsten
* Kontierung. Dieselbe Regel wie bei den Besetzungen — eine zweite Auslegung
* desselben Zeitraummodells wäre der sichere Weg zu zwei Antworten auf
* dieselbe Frage.
*/
export function kontierungZum(rows: KontierungsZeile[], asOf: string): Map<string, Kostenstelle> {
const out = new Map<string, Kostenstelle>();
for (const r of rows) {
if (r.valid_from > asOf) continue;
if (r.valid_to !== null && r.valid_to <= asOf) continue;
out.set(r.position_id, { id: r.cost_center_id, code: r.code, name: r.name });
}
return out;
}
/**
* Wie kontierungZum, aber für eine einzelne Planstelle und einen Stichtag,
* der nicht heute sein muss.
*
* Nötig für Planstellen, die erst entstehen: ihre Kontierung beginnt mit
* ihnen. Zu heute gefragt gäbe es keine — und die Vakanzliste, die künftige
* Stellen bewusst zeigt, stünde für genau diese ohne Kostenstelle da. Die
* Frage lautet dort nicht „wer zahlt heute", sondern „wer zahlt, wenn es
* losgeht".
*/
export function kontierungAm(rows: KontierungsZeile[], positionId: string, asOf: string): Kostenstelle | null {
for (const r of rows) {
if (r.position_id !== positionId) continue;
if (r.valid_from > asOf) continue;
if (r.valid_to !== null && r.valid_to <= asOf) continue;
return { id: r.cost_center_id, code: r.code, name: r.name };
}
return null;
}
/** Der bequeme Weg für Aufrufer ohne eigene Abfrage. */
export async function loadKontierungen(
tx: Tx,
{ asOf, positionIds }: { asOf: string; positionIds?: string[] }
): Promise<Map<string, Kostenstelle>> {
if (positionIds?.length === 0) return new Map();
const { rows } = await tx
.selectNoFrom((eb) => [jsonArrayFrom(kontierungenAbfrage(eb, positionIds)).as("rows")])
.executeTakeFirstOrThrow();
return kontierungZum(rows as KontierungsZeile[], asOf);
}