fegger
850e99df20
Close the premium-at-termination gap of the end-of-employment cycle: an aliquote periodic premium (annual, sales, bonus, 15th payment) whose entitlement period outlasts the termination is covered by § 16 AngG — the pro-rata amount follows the ratio of the elapsed service to the entitlement period, is due for employees regardless of the termination ground (loss clauses void, 9 ObA 82/13v), while performance-linked premiums for workers may validly hinge on non-fault grounds and premiums tied to a specific service (e.g. Bilanzgeld) are not aliquote without the service (lb-end-18). Two routes: PRAM_END (bemessung sonstig) covers premiums paid with the end-of-employment run — a special payment inside the annual sixth at the flat 6 % rate with the 620 EUR free amount and 2 615 EUR free threshold checked by the core, SV as special-payment contributions (KV/PV/AV without AK/WF) against the monthly HBG and the annual SZ cap, fully payroll-levy liable and BV-contributory at the uncapped 1.53 % rate (§ 6 Abs 1 iVm Abs 5 BMSVG). PRAM_END_TARIF (bemessung laufend plus the core l10n_at_s67_abs6_ueberhang flag) covers premiums due at a pre-agreed maturity because their amount only becomes determinable after the entitlement period ends (e.g. balance-sheet premiums): taxed like running pay with the payment-month tariff without touching the annual sixth (§ 67 Abs 10, not a § 67 Abs 8 lit c case per 98/14/0009 = ARD 5483/14/2004) — the SV contribution month rolls back into the termination year via a new payslip field consumed by an extended branch of the existing SV-basis-by-Beitragsmonat override (historical caps and rates, E-MVB 044-01-00-006), while the LSt stays in the payment month. The wizard section previews the § 16 pro-rata amount from the full premium, entitlement period and elapsed service, keeps the payable amount confirmable (KB agreement), requires the service/claim-basis confirmation, enforces the contribution month for the deferred case, and lands the memo on the payslip for the separate Lohnzettel workflow (LStR Rz 911a); the existing manual PRAM rule is untouched. The account matrix posts both rules to 6230. Verified against the original statute text in .ris/ (AngG § 16, BMSVG § 6 Abs 5) and the knowledge-base source lb-end-18; the full SZ roll-forward (storno plus recomputation against the termination year's SZ annual cap) and the mBGM storno/re-transmission remain open in the GP7 payroll-reporting track, and the BV attribution of the deferred premium remains in the payment month as a documented approximation. Version 19.0.16.0.0 (private)
odoo-at-payroll
Österreichische Personalverrechnung auf Odoo 19 Enterprise. Eigenes Repo
seit 2026-09-09 — Überführung aus gem360-git per History-Import; siehe
personalverrechnung/PLAN-repo-split.md.
Module
| Modul | Zweck |
|---|---|
l10n_at_hr_payroll |
Bundes-Kern (sektor-neutral): SV-Werte 2026 als hr.rule.parameter-Seed, TASY-Import-Wizard; folgen: Lohnsteuer (AP3), Meldewesen L16/eSV (AP5), Belege (AP6) |
l10n_at_gemeinde_payroll |
Bgld. GemBG 2014: Katalogmodell (AP1), Entgelt-Engine (AP2); AP3+ gemäß personalverrechnung/IMPLEMENTIERUNGSPLAN-Bgld.md |
l10n_at_hr_payroll_private |
General-AT (KV-basierte Privatwirtschaft) — Gerüst; Implementierungsplan freigegeben (IMPLEMENTIERUNGSPLAN-Privat.md), Umsetzung ab M1 (GP0) |
VRV-Buchung für Gemeinden (Anlage 3b, Ansatz/MVAG, EHH/FHH) läuft über
die Brücke l10n_at_gemeinde_payroll_vrv im gem360-Repo (AP7).
Abhängigkeitsrichtung: gem360 → dieses Repo, nie umgekehrt.
Entwicklung
- Odoo 19: Quellen-Referenz ist
odoo_19.0+e.20260910/odoo-19.0+e.20260910/(lokal, unversioniert, in.gitignore) — gemergter Baum (Community und Enterprise in einem Addons-Verzeichnis, 1.481 Addons, u. a.hr_payroll*,l10n_be_hr_payroll,l10n_ch_hr_payroll; Version19.0+e.20260910, Paketnameodoo, startbar viapython -m odoo). Die früheren Checkoutsodoo/+odoo_enterprise/(19.0.0) sind am 2026-09-11 entfernt worden; D4-Spot-Checks aus den Plänen wurden gegen 19.0.0 gemacht — gleiche relative Pfade, aber Neuzugänge wie immer zu Baubeginn gegen diesen Baum verifizieren (D4). Pin bei Odoo-Upgraden gegen den gem360-Entwicklungsstand validieren. - Runtime: Python 3.14 venv im Repo (
.venv/, in.gitignore; editable install des gemergten Baums) + PostgreSQL (Arch:postgresql-Paket, Cluster unter/var/lib/postgres/data,systemctl start postgresql). Dev-DB:odoo_dev. Rollen-/DB-Anlage einmalig:sudo -u postgres createuser -s <user>undcreatedb odoo_dev. - Planung/Rechtsquellen:
personalverrechnung/(PLAN, RECHTSQUELLEN, IMPLEMENTIERUNGSPLAN, Angebotskalkulation). - Rechts-Rohquellen:
.firecrawl/— lokal, unversioniert; falls fehlend, neu von RIS/sozialversicherung.at beschaffen (siehe payroll-Skill), niemals aus Trainingswerten arbeiten.
Tests
Wegwerf-DB verwenden (nie gem360_dev):
createdb <testdb>
.venv/bin/python -m odoo -d <testdb> \
-i l10n_at_hr_payroll,l10n_at_gemeinde_payroll \
--test-tags /l10n_at_hr_payroll,/l10n_at_gemeinde_payroll \
--test-enable --stop-after-init \
--addons-path=odoo_19.0+e.20260910/odoo-19.0+e.20260910/odoo/addons,addons
Der gemergte Baum enthält Community- und Enterprise-Addons in einem
Verzeichnis; kein separates odoo-bin mehr — Aufruf über
.venv/bin/python -m odoo. Dazu je Änderung: py_compile über
alle Python-Dateien und XML-Well-formedness-Check (Konvention wie im
gem360/vrv2015-Workflow).