# Implementierungsplan — Gemeinde-Personalverrechnung Bgld.
## Modul `l10n_at_gemeinde_payroll` (Odoo 19)

**Status:** Plan zur Freigabe (AGENTS.md-Workflow, Phase 3 — Implementierung
startet erst nach ausdrücklicher Freigabe). Basis: Rechtsquellen
(`RECHTSQUELLEN-Bgld.md`), Angebotskalkulation (APs, Prämissen P1–P10),
payroll-Skill. Alle Odoo-APIs wurden am vorliegenden Odoo-19-Source
verifiziert (Nachweise in Abschnitt 2).

- **Stand:** 2026-09-09 · Branch `dev-payroll` · lokal
- **Scope R1:** GemBG-Gemeindebedienstete (inkl. Kinderbetreuungspersonal);
  Optionen (Organe, Altpensionen, Lehrlinge, Folgebundesländer) und
  Ausschlüsse gem. Kalkulation Abschnitt 5/6.

## 1. Anforderung (Verständnis)

Vollständige Monatsverrechnung für Bedienstete burgenländischer Gemeinden
nach dem **Bgld. GemBG 2014**-Eigenregime: Entlohnung aus
Entlohnungsgruppen/-stufen (Jahreswerte aus Bgld. Bezügeanpassungs-
Sammelgesetzen), quartalsweise Sonderzahlung, Zulagen, Über-/Mehrdienst-
leistung; Lohnsteuer (§ 33/§ 68 EStG) und SV/Dienstgeberbeiträge (ASVG,
öffentlicher FLAF-DB, IESG); Belege (Lohnzettel, Monatsdienstliste,
Monatsjournal); Meldedateien (L16/FinOnl, eSV/ELDA-XML, Beitragsgrundlagen-
nachweis) — dateibasiert, Übertragung beim Kunden (P7); FI-Buchung auf den
VRV-Kontenplan mit Ansatz-/MVAG-Attribution und EHH/FHH-korrektem Verhalten
plus Abfertigungsrückstellung; Jahreswechsel-Prozess.

## 2. Verifizierte Odoo-Basen (Erweiterungspunkte)

| Mechanismus | Nachweis (odoo/addons/…) | Verwendung im Plan |
|---|---|---|
| `hr.rule.parameter` + Werte je `date_from` (Python-Datenstruktur, safe_eval) | `hr_payroll/models/hr_rule_parameter.py` | Alle jährlichen/variablen Werte: LSt-Tarif & Absetzbeträge, SV-Sätze, Grenzen, FLAF-DB-Satz, IESG, Überstundenfreibetrag |
| Konsum in Regeln: `payslip._rule_parameter('code')` | `hr_payslip.py` L951; Praxis l10n_be (`data/cp200/*_data.xml`) | Regeln lesen keine Literale |
| Regel-Kontext `localdict`: `categories`, `rules`, `payslip`, `worked_days`, `inputs`, `employee`, `result_rules`, `version` | `hr_payslip.py` L1051–1072 | Entgelt-/Abzugsregeln; GemBG-Komponenten als Work-Entry-Types/Inputs |
| Strukturen: `hr.payroll.structure` (mit `journal_id`), `hr.payroll.structure.type`; Zuordnung über Mitarbeiter-Version | `hr_payroll_structure.py`, `hr_version.py` | EINE Struktur „GemBG Bgld. Gemeindebedienstete“; Gruppen/Stufen über Vertragsfelder, nicht über Struktur-Vielfalt |
| Work-Entry-Types (`hr.work.entry.type`: Rounding, `unpaid_structure_ids`) | `hr_work_entry_type.py` | Dienstzeit-Komponenten: Über-/Mehrdienstleistung, Journaldienst, Bereitschaft, Karenz/Herabsetzung |
| Buchung: `hr.salary.rule.account_debit/account_credit` (company_dependent, restrict), Netto-Ausschluss-Flag, Tags | `hr_payroll_account/models/hr_salary_rule.py`, `hr_payslip.py` | Regel→VRV-Konto-Mapping direkt am Regelobjekt; Buchungs-ohne-Netto-Regeln für DG-Sicht |
| Posting-Batch je Journal+Monat: `_action_create_account_move` → `_prepare_slip_lines`/`_prepare_line_values`/`_prepare_adjust_line` | `hr_payroll_account/models/hr_payslip.py` L54–222 | **Hook:** Überschreiben von `_prepare_line_values`, um je Regel `budget_position_id` (Ansatz aus `l10n_at_vrv2015`) + korrekte HH-Attribution zu setzen |
| Retro/Korrekturen: `is_refund_payslip`, `_action_refund_payslips` | `hr_payslip.py` L130–735 | Korrekturläufe ohne Eigenbau |
| Batches `hr.payslip.run`; SEPA-Auszahlung `hr_payroll_account_iso20022` | Engine | Monatsläufe, Zahlungsdatei (FHH via Zahlungslauf) |

## 3. Modul-Layout (Dateien/Komponenten)

```
l10n_at_gemeinde_payroll/
  models/
    entlohnung.py          # Katalog: gemeinde.payroll.entlohnungsgruppe / -stufe
    hr_employee_contract.py# GemBG-Felder auf Employee/Contract-Version
    hr_salary_rule.py      # vrv_ansatz_id (+ VRV-Default-Konto je Regel)
    hr_payslip.py          # Posting-Hook (Ansatz/HH), SZ-Quartil-Helfer
    lohnsteuer.py          # § 33-Tarif als pure Python-Utility (unit-testbar)
    vorrueckung.py         # BDA-/Vorrückungstermin-Berechnung
    abfertigung.py         # §-130-Rückstellungs-Engine (Anwartschaft, Zuführung)
    l16_export.py          # FinOnl-L16-Export (Datei + Prüfprotokoll)
    elda_export.py         # eSV/ELDA-XML (JASV, An-/Ab-/Änderung, Fehlanzeige, BGN)
  data/
    structure_bgld.xml     # Structure-Type + Structure (Journal-Verweis)
    salary_rules_bgld.xml  # Kategorien + Regelinventar (Abschnitt 4.2)
    rule_parameters_2026.xml # LSt/SV/Grenzen/FLAF-DB/IESG/ÜStd-Freibetrag 2026
    katalog_bgld_2026.xml  # Entlohnungsgruppen/-stufen 2026 (aus RV 0715; Seed)
    work_entry_types.xml, input_types.xml
  wizard/
    bezuegeanpassung_import.py  # Jahreswechsel: Tabellen-Import + Validierung
    vorrueckung_run.py          # Vorrückungen je Stichtag anwenden (explizit)
  report/                   # Lohnzettel (AT-Layout), Monatsdienstliste, Monatsjournal
  security/ir.model.access.csv
  tests/  (Abschnitt 6)
```

## 4. Vorgeschlagene Umsetzung

### 4.1 Katalogmodell (AP1)

- `gemeinde.payroll.entlohnungsgruppe`: `code` (z. B. `gv1`, `gb3`), Name,
  `bundesland` (Auswahl; Bgld. befüllt, weitere Länder als Daten),
  Verwendungsbeschreibung.
- `gemeinde.payroll.entlohnungsstufe`: `gruppe_id`, `stufe` (int),
  `monatsentgelt`, `gueltig_ab` (Datum); unique(Gruppe, Stufe, gueltig_ab)
  → jährliche Versionen aus der Bezügeanpassung; Seed 2026 aus
  RV 0715 (`.firecrawl/bezuege2026-rv0715.md`), Folgejahre über den
  Import-Wizard (Tabellenpaste + Plausibilitätsprüfung ±x %).
- Mitarbeiter/Vertragsversion (erben in `hr.employee`/`hr.version`-Kontext):
  `entlohnungsgruppe_id`, `entlohnungsstufe` (bezogen auf Stichtag),
  `besoldungsdienstalter` (Datum; Anrechnungszeiten als Zusatzfelder),
  `vorrueckungstermin` (compute), Teilzeit-Ausmaß via Resource-Kalender.
- **Vorrückungen** werden nicht still im Lohnlauf mutiert: eigener
  Wizard/Cron je Stichtag mit Protokoll (Vorrückung ist besoldungs-
  rechtlich ein Verwaltungsakt mit Dokumentationspflicht).

### 4.2 Regelinventar (AP2–AP4)

Kategorien: `GEMBG_BRUTTO`, `GEMBG_ABZUG`, `GEMBG_NETTO`, `GEMBG_DG`
(Arbeitgeberanteile, buchungs-/journalwirksam), `VRV_BUCHUNG`
(nicht netto-wirksam).

| Regel (Code) | Quelle/Mechanik |
|---|---|
| `ME` Monatsentgelt | Katalog-Lookup Gruppe+Stufe(Stichtag); Prorate Ein-/Austritt (Konvention AP1: Kalender- vs. Arbeitstage) und Teilzeit-Ausmaß |
| `KIZU` Kinderzulage | Kinder-Anzahl × Satz (Rule-Parameter); **bei Teilzeit ungekürzt** (§ 59) |
| `FUZU/ERZU/JZU/SFZU/BERB` Funktions-/Erschwernis-/Journaldienst-/Sonn-Feiertags-/Bereitschafts-Bezüge | Inputs/Work-Entry-Types mit Sätzen aus Rule-Parametern |
| `UEZ` Über-/Mehrdienstleistung | Inputs + § 68-Pauschalbesteuerung (steuerfreier Anteil; 2026: max. 170 €/15 ÜStd — Mechanik nach LStR, siehe 8.) |
| `JUB` Jubiläumszuwendung | Stichtagslogik (Dienstzeit) aus § 89/§ 157d |
| `SZQ` Sonderzahlung | **Quartalsweise**: im Auszahlungsmonat (Ende Q) 50 % des Monatsentgelts (inkl. KIZU); anteilig bei unterbrochenem Vierteljahr (§ 60 Abs 3: „nur der entsprechende Teil“) |
| `LSTL` Lohnsteuer laufend | `lohnsteuer.py`-Utility: § 33-Tarif auf Jahres-Progressionsbasis (LStBMG-Systematik), Absetzbeträge (Rule-Parameter 2026) |
| `LSTSZ` Lohnsteuer SZ | Begünstigte Bezüge (§ 68 Abs 5/6): Grenzwerte aus Rule-Parametern; Zuordnung quartalsweiser SZ — offene Detailfrage (Abschnitt 8) |
| `SVDN` SV Dienstnehmer | KV+PV+AV mit je-Zweig-HBG (6.930 €/13.860 € SZ), Geringfügigkeits-Check (551,10 €), AV-Staffel § 2a AMPFG |
| `SVDG` SV Dienstgeber | DG-Anteile (KV/UV/PV/AV) |
| `FLAFDB` | Öffentlicher FLAF-DB (§ 49a ASVG; Satz als Parameter — P5, AP0-Wert) |
| `IESG` | Insolvenz-Zuschlag 0,10 % (DG) |
| `NETTO` | Kategoriensummen |
| Abfertigungs-Rückstellung | **Nicht** als Slip-Regel: eigene Engine (4.4) |

### 4.3 VRV-Buchung (AP7)

- Regel→Konto: `account_debit/account_credit` auf den Regeln (Anlage-3b-
  Konten Klassen 4/5/6; exakte Codes aus der **Buchungsmatrix AP0** mit der
  Gemeindebuchhaltung; Ansätze 2211/2212/… aus dem verifizierten
  Bereichsbudget-Export ableitbar).
- Regel→Ansatz: neues Feld `vrv_ansatz_id` (`vrv2015.va.position`,
  company_dependent) auf `hr.salary.rule`; der Posting-Hook setzt
  `budget_position_id` je Move-Line (Vererbung von `_prepare_line_values`)
  → damit laufen die Bezüge automatisch durch die bestehende Detailnachweis-/
  Anlage-1a/2a-Engine des `l10n_at_vrv2015`.
- EHH/FHH: Lohnlauf bucht EHH (Ergebnishaushalt); die Auszahlung läuft über
  den Zahlungsverkehr (SEPA/Iso20022) → FHH über die normale Zahlungs-
  Verrechnung des VRV-Moduls (kein Sonderweg).
- DG-Beiträge (SV-DG, FLAF-DB, IESG) als buchungswirksame Regeln ohne
  Nettoeffekt (Netto-Ausschluss-Flag der Engine).

### 4.4 Abfertigungsrückstellung (AP7)

`gemeinde.payroll.abfertigung`-Engine: Anwartschaft je Dienstverhältnis
(§ 130-GemBG-Matrix), monatliche Zuführungsberechnung, Buchungs-Wizard
(Aufwandkonto Ansatz 2211 ↔ Rückstellungskonto 37x) mit Verprobungs-
Anker zur VRV-Engine. Keine Pseudo-Slip-Regel.

### 4.5 Meldewesen (AP5, dateibasiert — P7)

- `l16_export`: Wizard → L16-Datei (FinOnl-Format; **Spec in AP0
  beschaffen**) + Prüfprotokoll; Jahresbelegmeldung bis Ende Februar.
- `elda_export`: eSV-XML-Dateien (JASV-Monatsmeldung, An-/Ab-/Änderung,
  Fehlanzeige, Beitragsgrundlagennachweis; **eSV-XML-Spec in AP0**) +
  Validierungsprotokoll.
- Struktur der Dateien als Schema-Test gegen Spec-Beispiele (Abschnitt 6).

### 4.6 Jahreswechsel (AP8)

- Bezügeanpassungs-Import-Wizard (Tabellen des neuen Sammelgesetzes →
  neue `entlohnungsstufe`-Versionen; Plausibilitätsprüfung, Freigabe,
  Änderungsprotokoll).
- `rule_parameters_<jahr>.xml` je Jahr (LSt/SV/Grenzen) als normale
  Modul-Daten; Fristenkalender (L16 Ende Februar, JASV 15. Folgemonat —
  AP0 verifizieren).

## 5. Daten-/Modell-/Report-Implikationen

- Multi-Company je Gemeinde unverändert über Engine/Security; Katalog-
  Daten global (kein `company_id`), Regeln company-dependent-Konten.
- Reports: Lohnzettel = Payslip-Report im AT-Layout (qweb), Monatsdienst-
  liste (je Mitarbeiter/Periode), Monatsjournal (je Ansatz/Konto, DG-Summen)
  — alles qweb auf `hr.payslip`/Aggregaten, keine eigene Reporting-Engine.
- Rechenfall-Dokumentation je Regel (im `docs/` des Moduls) als Review-Grundlage.

## 6. Tests (hinzuzufügen)

`tests/` mit Rechenfall-Suiten (Lohntarif- und SV-Werte aus den verifizierten
2026er Quellen; Katalogwerte aus RV 0715):

1. `test_katalog`: Import 2026, Versionierung, Lookup Stichtag, Vorrückungstermin
2. `test_entgelt`: Vollzeit/Stufe; Teilzeit 50 % (KIZU ungekürzt); Eintritt
   am 15. (Prorate); Überstunden; Journaldienst/Bereitschaft; Jubiläum
3. `test_sz_quartalsweise`: Q-Ende voll; unterbrochenes Vierteljahr anteilig
4. `test_lohnsteuer`: Tarifgrenzen 2026 (0 %-Zone, Mittelzone, > 104.859),
   § 68-ÜStd-Pauschale, SZ-Behandlung (per LStR-Konvention AP0)
5. `test_sv`: HBG je Zweig inkl. SZ-HBG; Geringfügigkeit 551,10 + § 53a;
   AV-Staffel; FLAF-DB (Parameter); IESG 0,10 %
6. `test_posting_vrv`: Regel→Konto/Ansatz; Summe je Ansatz = Summe Regel;
   **L2-Anker: Kontenklasse-5-Ist des Lohnlaufs = Anlage-1a-Engine-Wert**
   (Muster wie im VRV-Modul); Rückstellungszuführung
7. `test_meldewesen`: Schema-/Beispielvalidierung L16 + ELDA (sobald Specs);
   Prüfprotokolle
8. Refund-Lauf (Korrektur) ohne Doppelbuchung

## 7. VRV-/Buchhaltungs-Überlegungen

- EHH zuerst, FHH über Zahlungsverkehr (keine künstlichen FHH-Buchungen im
  Lohnlauf); § 12/Barvorlagen irrelevant für Personal.
- Ansatz-Attribution über `budget_position_id` je Move-Line (bestehende
  Felder/Engine des VRV-Moduls; keine Parallelstruktur).
- Rückstellungen (Abfertigung § 130) buchungsseitig mit Verprobungsankern;
  Altpensionen/Versorgung sind **Option O2**, nicht R1.

## 8. Risiken / offene Fragen (vor Implementierungsbeginne in AP0 klären)

1. **Buchungsmatrix**: exakte Anlage-3b-Konten je Bezugsart mit der
   Gemeindebuchhaltung (AP0-Workshop) — Voraussetzung für 4.3.
2. **FLAF-DB öffentlich (P5)**: exakter aktueller Satz § 49a Abs 8/9 ASVG
   (RIS-Verifikation; Firecrawl-Limit ausnehmen).
3. **SZ ↔ Lohnsteuer (P9)**: quartalsweise SZ in der § 68 Abs 5/6-Systematik
   (LStR 2002; ggf. BMF-Auskunft) — betrifft Regel `LSTSZ`.
4. **ELDA-/FinOnl-Specs**: Beschaffung + Testdaten (AP0) — bis dahin werden
   die Exporte als „strukturvalidiert gegen Spec-Beispiel“ abgenommen.
5. **Prorate-Konvention** Ein-/Austritt (Kalender-/Arbeitstage) aus
   GemBG § 64 und Praxis der Gemeinde (AP0/Bestandsaufnahme).
6. **SV-Träger** ÖGK Bgld. (P6) aus Unterwart-Läufen bestätigen.
7. Bestands-Sonderfälle (Lehrlinge/Organe/Altpensionen) — Optionen O1–O3.

## 9. Meilensteine (AP-Mapping, post-Auftragserteilung)

| M | Inhalt | APs | Dauer |
|---|---|---|---|
| M0 | Freigabe dieses Plans | — | heute |
| M1 | Bestandsaufnahme Pilotmandant, Buchungsmatrix, P5/Träger/Specs, Konventionen | AP0 | ~2 Wo |
| M2 | Katalogmodell + 2026er Daten + Vertragsfelder + Erstläufe intern | AP1 | ~3 Wo |
| M3 | Entgelt-Engine (Zulagen/ÜStd/SZ), Lohnsteuer, SV/DB | AP2–AP4 | ~6 Wo |
| M4 | Meldedateien + Belege | AP5–AP6 | ~4 Wo |
| M5 | VRV-Buchung + Rückstellung + Jahreswechsel-Importer | AP7–AP8 | ~3 Wo |
| M6 | Rechenfall-Suiten komplett, UI/Security/Doku/Schulung, **2–3 Monate Parallellauf**, Abnahme | AP9–AP10, PM | ~2,5 Mo |

Gesamtkalkulation unverändert ≈ 260 PT (Kalkulationsdokument);
M1-M5 sequenziell, M6 teilweise parallel zu M3–M5.

## 10. Freigabe-Antrag

Mit Freigabe dieses Plans startet die Umsetzung mit **M1 (AP0)** und
anschließend M2 (AP1: Katalogmodell + Seed-Daten + Vertragsfelder).
Änderungen am Scope (Prämissen-Verletzungen, Optionen) laufen über
Change-Requests.