[ADD] personalverrechnung: Plan SV-Werte-Implementierung (TASY-LSWH)

Analyse des ÖGK-TASY-Exports (Stichtag 2026-07-01, 5 MB): tarife/tarifsets/
tarifgruppen/beschaeftigtengruppen-Kette mit DN/DG-Anteilen je Zweig
(KV/PV/AV/UV/IE/DG/AK/WF/BV), bbwerte in Cent mit Gültigkeit; verifizierte
Deckung mit dem SV-Werte-Report 2026 (GFG 551,10 EUR, HBG SZ 13.860 EUR,
KV 3,87/3,78, AV 2,95/2,95). Plan: hr.rule.parameter bleibt alleiniger
Wertespeicher (Engine-Mechanik, Konsum via payslip._rule_parameter);
Seed 2026 per Generator mit Herkunftsnachweis + jährlicher
TASY-Import-Wizard (stichtagsbasierte Auflösung über die Gruppenkette,
Preview-Differenz mit Plausibilitätswarnung, explizite Bestätigung) +
Mapping-Tabelle TASY-Code/Zweig -> Parameter. Nicht in TASY: öffentlicher
FLAF-DB (§ 49a Abs 8/9, AP0/RIS), Lohnsteuer, KommSt. Offene Punkte
(HBG x30-Konvention, AMPFG-Staffelauflösung, Commit der 5-MB-Quelldatei)
im Plan dokumentiert; Freigabe-Antrag gestellt.
This commit is contained in:
2026-09-09 12:26:14 +02:00
parent 30270f9877
commit 8e0b169b73
+119
View File
@@ -0,0 +1,119 @@
# Plan — SV-Werte-Implementierung (AP4) auf Basis TASY-LSWH-Export
**Status:** Plan zur Freigabe (AGENTS.md-Workflow). Ergänzt den
freigegebenen `IMPLEMENTIERUNGSPLAN-Bgld.md` (AP4/AP8) um den
TASY-gestützten Wertelayer.
- **Stand:** 2026-09-09 · Branch `dev-payroll`
- **Quelle:** `personalverrechnung/TASY-LSWH-Export-20260324.xml`
(ÖGK-Tarifsystem-Export, Gültigkeitstichtag 2026-07-01, 5 MB)
## 1. Befunde aus der Datei (verifiziert)
| Aspekt | Befund |
|---|---|
| Aufbau | `tarife` (356) mit DN/DG-Anteil je `tarifZweig` + Gültigkeit; `tarifsets`/`tarifgruppen`/`tarifgruppeSetZuordnungen` als Zuordnungskette zu `beschaeftigtengruppen` (B-Codes, 408); `beitragbemessungsbetraege` (158 Codes) mit `bbbwerten` (612, **Cent-Werte** je von/bis) |
| Zweige | KV, PV, AV, UV, **IE (Insolvenz/IESG)**, DG (SV-Dienstgeberbeitrag), AK, WF, BV, LK, SW, … |
| Verifizierte 2026er Werte | Geringfügigkeitsgrenze **551,10 €** (`GFGBTG`), HBG SZ **13.860 €** (`HBGSZ`), KV-Split **3,87/3,78**, AV **2,95/2,95**, PV-DG **12,55** — deckungsgleich mit dem offiziellen SV-Werte-Report 2026 ✓ |
| Raten-Auflösung | Am Stichtag gelten je Zweig 2167 Tarif-Varianten (Sondergruppen, §-2a-AMPFG-Staffelanteile, freie DN …). Der **Standard-Angestelltensatz** muss über `beschaeftigtengruppe` (z. B. „Angestellte") → `tarifgruppeSetZuordnung``tarifset``tarife` aufgelöst werden |
| Nicht enthalten | Öffentlicher FLAF-DB (§ 49a Abs 8/9 — null Treffer), Lohnsteuer, Kommunalsteuer → bleiben separate, RIS/usg-basierte Parameter (AP0) |
| Offene Detailpunkte | HBG monatlich = `HBGALLG` (tgl.) × 30 oder eigener bbbwert; exakte Abbildung der §-2a-AMPFG-Staffel über Tarif-Varianten (Grenzwerte werden zusätzlich gegen den SV-Werte-Report gespiegelt) |
## 2. Zielbild
Zwei Schichten — **kein Eigenbau-Speicher**, die Engine-Mechanik bleibt
alleiniger Wertespeicher:
1. **Seed 2026** (`data/rule_parameters_2026.xml`): `hr.rule.parameter`
+ `hr.rule.parameter.value` (date_from = Stichtag) aus DIESEM Export,
einmalig per Generator-Script generiert und gegen den SV-Werte-Report
2026 gespiegelt (Herkunftsnachweis wie beim GemBG-Katalog).
2. **TASY-Import-Wizard** (`gemeinde.payroll.tasy.import.wizard`,
TransientModel) für die Jahrespflege (AP8):
- Upload des jährlichen Exports (ir.attachment), sicheres Parsen
(lxml, resolve_entities=False);
- Auflösung am `gueltigkeitstichtag`: bbwerte der Mapping-Codes
(Cent→€) + Standard-Raten über die Gruppenkette; fehlende/
mehrdeutige Auflösungen landen zur manuellen Klärung im Preview;
- **Preview-Differenz** (Parameter, alter Wert, neuer Wert,
Stichtag, Plausibilitätsprüfung ±10 % Sprungwarnung);
- Bestätigung schreibt `hr.rule.parameter.value` (date_from =
Stichtag; historische Werte bleiben versioniert), Protokoll.
3. **Mapping-Tabelle** `gemeinde.payroll.tasy.mapping` (TASY-Code/Zweig →
rule-parameter-code) als data XML — transparent, ohne feste Werte im
Code, erweiterbar (z. B. BVAEB-Export später).
Regeln (AP2/AP4) konsumieren ausschließlich
`payslip._rule_parameter('at_sv_kv_dn')` usw. — keine Literale
(payroll-Skill-Architekturregel).
## 3. Parameter-Katalog (Seed 2026)
| hr.rule.parameter | Wert 2026 | TASY-Quelle |
|---|---|---|
| `at_sv_gfg_monatlich` | 551.10 | GFGBTG |
| `at_sv_hbg_monatlich` | 6.930,00 | HBGALLG (tgl. 231,00 × 30; Auflösung klären) |
| `at_sv_hbg_sz_jaehrlich` | 13.860,00 | HBGSZ |
| `at_sv_kv_dn` / `at_sv_kv_dg` | 3.87 / 3.78 | Tarif KV (Standard-Angestellte) |
| `at_sv_pv_dn` / `at_sv_pv_dg` | 10.25 / 12.55 | Tarif PV |
| `at_sv_av_dn` / `at_sv_av_dg` | 2.95 / 2.95 | Tarif AV |
| `at_sv_uv_dg` | 1.10 | Tarif UV |
| `at_sv_iesg_dg` | 0.10 | Tarif IE |
| `at_sv_bv_dg` | 1.53 | Tarif BV |
| `at_sv_ak_dn` / `at_sv_wf_…` | (geführt; für GemBG nicht anwendbar — Datenbasis vollständig, Anwendungslogik entscheidet) | AK/WF |
| `at_sv_av_staffel_ampfg` | Grenzen 2.225/2.427/2.630 + Anteile 0/1/2 % | SV-Report + TASY-Kreuzcheck |
**Getrennt gepflegt (nicht TASY):** `at_flaf_db_oeffentlich`
(§ 49a Abs 8/9 — AP0/RIS), Lohnsteuer-Parameter (usp/RIS).
## 4. Umfang / Dateien
```
l10n_at_gemeinde_payroll/
models/tasy.py # gemeinde.payroll.tasy.mapping + import-wizard
data/rule_parameters_2026.xml # Seed (generator-erzeugt)
data/tasy_mapping.xml
wizard/… (transient im models-File oder wizard/ je nach Konvention)
views/tasy_views.xml # Mapping-View + Wizard-Form
security/ir.model.access.csv (Ergänzung)
tests/test_tasy_import.py # Parser-/Resolutions-Tests (kleines Fixture)
personalverrechnung/tools/gen_sv_parameters_2026.py # Herkunftsnachweis
```
Die 5-MB-Exportdatei: **Vorschlag** unter
`personalverrechnung/quellen/TASY-LSWH-Export-20260324.xml` committen
(öffentliches Tarifdatenmaterial, keine Personendaten) — oder unversioniert
lassen, wenn du das Repo klein halten willst (bitte entscheiden).
## 5. Tests (Rechenfälle)
1. Parser: Fixture-Slice (handgebaut, gleiche Struktur) → bbwerte
Cent→€, Stichtagsfilterung, fehlende Werte → Preview-Fehler.
2. Auflösung: Standard-Raten für „Angestellte" (KV 3.87/3.78 …) aus der
**echten Exportdatei** (Test liest sie aus dem Repo, wenn committet;
sonst aus dem Fixture mit den verifizierten Werten).
3. Seed-Spiegelung: `at_sv_kv_dn` == 3.87 usw. gegen SV-Werte-Report
(gleiche Anker wie RECHTSQUELLEN Abschnitt 4).
4. Wizard: neuer Stichtag → neue `hr.rule.parameter.value`, alte
Version bleibt; Sprungwarnung bei >10 % Abweichung.
5. HBG-Rechnung tgl. × 30 gegen monatlich (je nach Auflösungsvariante).
## 6. Risiken / offene Fragen
1. Auflösungstiefe der Tarif-Varianten (Standardgruppe vs. Sonderfälle)
— im Wizard als Preview-Schritt sichtbar, mehrdeutige Sätze werden
nie automatisch übernommen.
2. HBG monatlich (×30-Konvention vs. eigener bbbwert) — Klärung in der
Implementierung mit Quellenabgleich.
3. TASY liefert ÖGK-Werte; BVAEB-Angelegenheiten (falls je benötigt)
folgen über dasselbe Mapping-Modell als eigener Import.
4. FLAF-DB öffentlich bleibt AP0 (RIS) — bewusst außerhalb TASY.
5. Verbindlichkeit: Wizard schreibt erst nach expliziter Bestätigung
(kein stiller Jahresüberschreib).
## 7. Freigabe-Antrag
Mit Freigabe: (a) TASY-Datei committen ja/nein (Abschnitt 4), (b)
Seed 2026 generieren + `rule_parameters_2026.xml`, (c) Mapping-Modell +
Import-Wizard, (d) Tests; Gesamtaufwand ~69 PT (in AP4/AP8-Kalkulation
enthalten — ersetzt die dort angesetzte manuelle Wertepflege zum Großteil).