fegger
27654211fb
Buchungsmatrix nach dem Oesterreichischen Einheitskontenrahmen (KFS/BW 6; Nutzer-Referenz-Exemplar .additional_docs/KFSBW6_13072017_RF.pdf): Hook _configure_payroll_account_at (models/account_chart_private.py) ordnet Regelkonten, Journal SLR (Default = Gehaelterkonto 6200, BE-Muster) und das NET-Konto 3850 "Verbindlichkeiten aus Lohn und Gehalt" (Nutzer-Entscheidung 5.1; Anlage + reconcile, l10n_at-Standardchart hat es nicht) je Company zu — getriggert beim Chart-Load (_post_load_data) UND ueber die <function>-Datendatei data/hr_payroll_account_private.xml fuer Bestands-Companies (erster <value> einer function ist die Record-ID-Liste, convert.py-Semantik), idempotent. Konto-Suche exakt zuerst, Praefix-Fallback nur bis eine Stelle laenger — verhindert Matches auf Odoo-Scaffold-Konten chartloser Firmen (6000 darf nicht 600000 "Expenses" matchen). EKR-Debit-Split Arbeiter/Angestellte (Nutzer-Klaerung: 600-619 Loehne, 620-639 Gehaelter — "6000 Gehaelter/6200 Loehne" war gegen die eigene KFS/BW-6-Referenz vertauscht): l10n_at_personalgruppe am Vertrag (models/hr_version_private.py) + Override-Feld l10n_at_account_debit_arbeiter je Regel; Option A minimal (Nutzer-Entscheidung 5.2: Grundentgelt 6000, Sozialaufwand 6500, Abgaben 6600/6601/6602; Zuschlaege/UeStd/Praemien/SZ und BV (EKR 644 ohne Split) buchen fuer Arbeiter bis zur Referenzbuchhaltungs-Fixierung auf die Angestellten-Konten — fehlende Konten warnen, keine Erfindung). models/account_posting_private.py: Gesamtueberschreibung von _prepare_slip_lines nach Upstream-Muster (Odoo-Pin 19.0+e.20260910) mit einzeiliger Kontosubstitution — Odoo bietet dafuer keinen Override-Punkt; Verhalten testgepinnt. Matrix: KVGEO/URL_UE 6200/6000, Zuschlaege 6225, UeStd 6310, Praemien 6230, B13/B14 6240, DN-SV/LSt auf 3600/3540, NET 3850, SVDG-Block 6560/6500 auf 3600, BVG 6440 (Fallback 6400) auf Credit 3600 (Abfuhr via KV-Traeger, Nutzer 5.3), FLAFDB 6661/6601 auf 3541, KOMMST 6660/6600 auf 3550, DZ 6662/6602 auf 3542. NET-Umbenennung NETTO -> NET (Odoo-Konvention: action_register_payment, net_wage und Negativ-Netto-Erkennung filtern code == NET) inkl. 4 Bestands-Suiten. Odoo-19-Fund: das Anlegen einer Structure kopiert die Regeln des hr_payroll.default_structure (BASIC/GROSS/NET/...) via Feld-Default in rule_ids — die kopierte Default-NET-Regel kollidierte im result_rules-Dict (Netto fiel auf 0); Fix: <function> in salary_rules_private.xml archiviert die Kopie (active=False; KEIN Unlink — struct_id ist NOT NULL und historische Lohnkontolinien behalten ihre Regel-Referenz; One2many blendet Archivierte aus). Journal-Default-Konten duerfen nicht Receivable/Payable sein (Odoo-Constraint); Rundungscents bucht Odoo als Adjustment Entry aufs Journal-Default. depends: + l10n_at, hr_payroll_account_iso20022 (SEPA-Auszahlung, Plan 4.5; kein VRV/MVAG — gem360-Bruecke). Tests: test_account_private (4: RF-BUCH-1..4 — Kontenplan-Mock ohne Chart-Install, Move-Balance, Kontenzeilen je Matrix, Arbeiter-Split, Geringfuegiger, Fallback/Warnung) — gesamt 88/88 gruen auf Wegwerf-DB (frischer -i-Lauf). Rechenfaelle docs/rechenfaelle/buchhaltung.md. 19.0.6.0.0.
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).