T

fegger c474a39466 [IMP] l10n_at_hr_payroll: GP7 ELDA-Fixsatz-Framework, L16 + Arbeitsstättenmeldung, Kind-Modell, Belege (AP5/AP6)

ELDA-Fixsatz-Framework (models/elda.py) nach DM-ORG 42.7.0 Kapitel C.1/C.2+E.1-E.3: Fixlängen-Sätze ohne Feldtrennzeichen (a/a-n linksbündig, Grundstellung blank; n rechtsbündig, Grundstellung 0, führende Nullen, KEINE Interpunktion — Beträge EURO-Cent kaufmännisch gerundet, Prozentsätze x1000 mit 3 Nachkommastellen), Encoding ISO-8859-15 (Standard-Encoding für Fixlängen), optionaler Dateiheader (DHKZ 2x blank + DHVN 01 + ENCD), Vorlaufsatz SART 00 (BEST/VSTR/VERS) + Schlusssatz SART 99 mit SANZ; SANR lückenlos ab 1 je Datenbestand; CRLF als Satztrenner (Praxis-Annahme, DM-ORG normiert keines — Parallellauf verifizieren).

Lohnzettel Finanz L16 (models/lohnzettel_l16.py): Informationssatz I1 (SART I1, Länge 1.100, Strukturversion 03) + Mitteilungssatz L1 (SART L1, Länge 3.500, Lohnzettelversion 28 — zwingend ab 01.03.2026) mit vollständiger, PDF-verifizierter Feldtabelle (~210 Felder inkl. Kinderblock 15x123 ab Pos. 1501; DM-ORG 42.7.0 E.13/E.14). KZ-245-Formel: KZ 210 = Bruttobezüge gem. § 25 GESAMT (DM-ORG-Feldbeschreibung) — die Formel 210-215-220-230-243 ergibt die laufende Steuerbemessung, per Konstruktion konsistent mit der GP3-§-66-Kette (Ableitung aus l10n_at_bemessung/steuerbefreiung_68/s67_abs und Regelcodes; bewusst KEIN paralleles KZ-Klassifikationsfeld). Arbeitsstättenmeldung § 34 Abs 6 ASVG: SART 45 (Länge 300, Version 02, BEST AD/VSTR ST Statistik Austria) je AN am 31.12. aus dem Dienstort-Partner (GKZ manuell, Warnung wenn fehlt) — im selben Jahreslauf (Nutzer-Entscheidung 5.1).

Kind-Datenmodell (models/kind.py — l10n.at.payroll.kind): Stammdaten-Wartung des Familienbonus Plus (Nutzer-Entscheidung 5.3: FB+ rechnet NICHT im Lohnsteuerkern — bei Unterschreiten der Steuer auf 0 erfolgt die Geltendmachung über die Arbeitnehmerveranlagung); Felder für den L16-Kinderblock (Familienname/Vorname/Geburtsdatum/VSNR/Staatsangehörigkeit/FB+-Monate voll/halb, Alterstaffel 166,68/58,34).

Stammdaten (models/meldewesen.py): Beitragskontonummer BKNR + Lohnsteuernummer (res.company), Gemeindekennziffer GKZ (res.partner), VSNR-Formatprüfung LLLPTTMMJJ auf hr.version.ssnid (Prüfzifferalgorithmus = dokumentierter Rest, SVS-Quelle beschaffen), eSV-Abmeldegrund AGRD-Mapping auf hr.departure.reason (Standard 00); fallweise-Beschäftigungs-Flag auf hr.version (§ 33 Abs 1a Z 1 ASVG).

Belege (AP6): Lohnzettel AT (ir.actions.report auf hr.payslip, AT-Layout mit Bezügen/DN-Abzügen/DG-Anteilen/Netto), Monatsdienstliste (mBGM-Kontrollschicht je AN) + Monatsjournal (je Lohnart Summen je Lauf) auf hr.payslip.run als QWeb (models/monatsreports.py + report/belege_reports.xml; account.report wird in keinem HR-Modul genutzt).

Tests: test_elda_l16 (4 — Feldformatierung/Cent-Beträge/skala, Bestands-Assembly SANR/SANZ/CRLF/ISO-8859-15/Dateiheader, L16-Lauf mit positionsexakten Assertions aus der November-Fixture, Arbeitsstätten-Satz). 19.0.4.0.0.

2026-09-12 17:30:59 +02:00

.agents

[IMP] odoo-at-payroll: GP6-Bau, KFS/BW-6-Abgleich und Odoo-19-Mechanik-Funde dokumentiert

2026-09-12 12:59:00 +02:00

addons

[IMP] l10n_at_hr_payroll: GP7 ELDA-Fixsatz-Framework, L16 + Arbeitsstättenmeldung, Kind-Modell, Belege (AP5/AP6)

2026-09-12 17:30:59 +02:00

docs

[IMP] odoo-at-payroll: GP6-Bau, KFS/BW-6-Abgleich und Odoo-19-Mechanik-Funde dokumentiert

2026-09-12 12:59:00 +02:00

personalverrechnung

[IMP] odoo-at-payroll: GP6-Bau, KFS/BW-6-Abgleich und Odoo-19-Mechanik-Funde dokumentiert

2026-09-12 12:59:00 +02:00

.gitignore

[IMP] personalverrechnung: resolve KB conflict families A1-A10 and B1-B18 against primary sources

2026-09-11 16:32:19 +02:00

AGENTS.md

[ADD] odoo-at-payroll: opendataloader-pdf agent skill for PDF extraction

2026-09-12 09:32:21 +02:00

README.md

[IMP] odoo-at-payroll: record GP0 source work and GP1 runtime setup in docs

2026-09-11 11:15:42 +02:00

README.md

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).