fegger
e6598d01cf
First WIKU Personal intake (30 licensed publications, source Stands 2023-07 to 2026-09), integrated into the shared curated corpus per the integration model of 2026-09-10: one corpus, the work field distinguishes the sources, WIKU entries use the wk-<prefix>-<nn> id space on the existing cluster map, Layer-2 filenames carry the wiku_ prefix. The corpus grows to 601 curated entries in 69 clusters. - 30 publications: 13 Fachbroschueren, 3 Arbeitsunterlagen, 2 Casebooks (geloesste LV-Praxisfaelle) and the twelve 2026 issues of the periodical 'WIKU Personal aktuell' (new cluster akt with wk-akt-01..12); second new cluster gwe for the trade-specific brochures (Gueterbefoerderungsgewerbe, Gastgewerbe); the remaining 16 publications sit on existing clusters (wk-pfa-01 next to lb-pfa-*: vor, kar, bnd, lvr x2, dvh, bes, rei, gsf, grz, ins, lsd, pfa, azg, sac, son) - tooling: multi-source extension of build_lexis_kb.py (--source lexis|wiku|all for --extract and --check, --registry over both sources); WIKU metadata comes from an explicit WIKU_PINS table (slug, cluster, stand, work, chapter, title) instead of Lexis breadcrumbs - a PDF without a pin is a hard warning and is never extracted; WIKU page-counter footer lines dropped (WIKU_PAGE_RE); fix in curated_slugs_for(): the .md suffix is now stripped when the wiku_ prefix is removed, so the wiku --check completeness gate passes - curation: the twelve periodical issues were curated in six parallel agent groups, each grounded only in its Layer-1 text with a self-check on frontmatter/structure/cross-refs; the 19 brochure entries from the prior session were re-validated centrally; 30/30 green - registry and check green: lexis 571/571 and wiku 30/30 curated, 0 problems; kb.json and INDEX.md regenerated (601 entries, 69 clusters, sources and per-source batch counters recorded) - wissensbasis README: two-source corpus documentation (layers, frontmatter schema incl. WIKU works and id spaces, cluster table with akt/gwe, per-source update cycle) - flagged for RIS (documented in the entries): wk-akt-01 par. 124b 'z 440/492' (pre-BGBl stand of 2026-01) and the wk-akt-07 Mitarbeiterpraemie citation contradiction 'z 478 vs z 477' (z 478 lit f binding); the Feiertagsarbeitsentgelt/UEStd repair is resolved via BGBl I 43/2026 in wk-akt-04 and matches the binding legal position; new conflict family wk-akt-11 (SV employee shares on par. 68 benefits caught by the par. 20 Abs 2 Z 1 EStG deduction ban, 'Formel 7' at risk); wk-akt-10 free-contractor DN rate 17.57% vs arithmetic 17.07% without WF; wk-akt-07 Wien WF 1.5% (lb-lnk-05 family); ALV-Entfall draft vs final act (wk-akt-03 vs 04); 2027 SV values provisional (wk-akt-05/06)
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).