fegger 14940ac31a [IMP] l10n_at_hr_payroll_private: GP7 mBGM/JASV + Versichertenmeldung + fallweise Anmeldung auf dem ELDA-Framework
mBGM/JASV (models/mbgm.py — DM-ORG 42.7.0 E.32, BEST MB, Version 02): Paket PS (BKNR/DGNA/BZRM/GSUM/ANZM) → mBGM G1 (REFW/VSNR/FANA/VONA/VSUM/VERG=1) → Tarifblock T1 (BSGR/VVON) → Verrechnungsbasis BS (VBTY/VBBT) → Verrechnungsposition V1 (VPTY/VPVZ/VPTA/RSVZ/RSUM). KEIN DN/DG-Zweig-Split: T01 = GESAMT-Prozentsatz des Tarifsystems je Beschäftigtengruppe (Parameter at_mbgm_tarif, normativ: laufend 39,05 % = KV 7,65 + PV 22,80 + AV 5,90 + UV 1,10 + WF 1,00 + IESG 0,10; SZ 37,55 % = DN KV 3,87 + PV 10,25 + AV 2,95 + DG 20,48). Abschläge als EIGENE Verrechnungspositionen je Basis: A03/A02/A01 = Minderung AV auf 0/1/2 % (§ 2a AMPFG, nur DN-AV, je Verrechnungsbasis AB UND SZ), A09 = UV-Entfall 60, A10 = AV+IE-Entfall Pensionsanspruch (Konkurrenz a4: sperrt Staffelabschlag), A15 = PV-Halbierung Bonusphase — konsistent mit der GP4-§-2a-DN-seitig-Konvention. BV (BMSVG): eigene Verrechnungsbasis BV (ungedeckelt, GP5) + Position V01 1,53 %. RSUM = Basis x Satz (mBGM-Tarifierung), Konsistenz-Check gegen GP4-Payslip-Beitragssummen ±0,10 € als Prüfwarnung. Storno: R1-Sätze mit REFU/VSUM wie Original. Fehlanzeige: Paket ohne mBGM-Sätze (ANZM 0). Geringfügige/fallweise ohne Parametrisierung: listenweiser Abbruch (keine Tarif-Erfindung; BSGR B044/B045/B010/B030 aus dem SV-Tarifsystem pflegen).

Versichertenmeldung (models/versichertenmeldung.py — DM-ORG E.29, BEST VR, Version 03, Satzlänge 772): M3 vor Arbeitsantritt / M4 (7 Kalendertage ab PV-Ende) mit deklarativer Event-Erkennung über die Meldungs-Registry (l10n.at.payroll.vr.event) — idempotente Läufe, Dimona-auto-Idee ohne write-diff-Hacks. Felder: BKNR/VSNR/GEBD/FANA/VONA (Namenssplit am letzten Leerzeichen), ADAT/EBSV, BBER 01-04 aus l10n_at_personalgruppe/lehrling, GERF (Kataloggehalt vs. GFG), FRDV, BVAB/BVJN aus dem GP5-BMSVG-Flag, VWAZ (Stunden x100, neu ab 01.01.2026), AGRD aus dem hr.departure.reason-Mapping (Standard 00). Fallweise Anmeldung (BEST MA, SART 32, Version 07, Länge 450): MVP je Anmeldetag am Vertragsbeginn; tagesgenaue Einsatztage via Work-Entry-Auswertung = dokumentierter Rest.

NSchAB-Branche als Company-Flag (l10n_at_nschab): B001-T01 + 3,80 % (Schlechtwetterentschädigung, ÖGK-Tarifsystem Normalbetriebe mit Schlechtwetterentschädigung).

Tests: test_meldewesen_private (2 — mBGM-Satzhierarchie mit A03 je Basis aus November-Fixture + GSUM-Konsistenz; VR M3/M4 mit Registry-Idempotenz und AGRD). Rechenfälle docs/rechenfaelle/meldewesen.md. 19.0.7.0.0.
2026-09-12 17:31:12 +02:00

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; Version 19.0+e.20260910, Paketname odoo, startbar via python -m odoo). Die früheren Checkouts odoo/ + 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> und createdb 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).

S
Description
No description provided
Readme 54 MiB
Languages
Python 99.7%
Shell 0.3%