Files
odoo-at-payroll/README.md
T

74 lines
4.1 KiB
Markdown

# 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`](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_payroll_dokumente` | **Dokumente aus Vorlagen**: Dokumentgenerierung (Dienstvertrag, Kündigung, Bescheinigungen …) aus hr-Stammdaten; eigene Texte, Struktur-Referenz (kb_ref) dokumentiert; Wizard mit Auto-/Manuellfeldern, Vorschau, PDF/HTML-Ablage |
| `l10n_at_hr_payroll_private` | **General-AT** (KV-basierte Privatwirtschaft) — Gerüst; Implementierungsplan freigegeben ([`IMPLEMENTIERUNGSPLAN-Privat.md`](personalverrechnung/IMPLEMENTIERUNGSPLAN-Privat.md)), Umsetzung ab M1 (GP0) |
| `l10n_at_payroll_agent` | **Agenten-Brücke** (M4.1): Plausibilitätsprüfung einer geplanten Auszahlung — serverseitiger Client ruft den pv-agent-Service per `/v1/ask` `mode=review` auf; depends `l10n_at_hr_payroll_private` |
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.
## Wissensbasis-Agent (pv-agent/)
Seit 2026-09-17 Teil dieses Repos (Subtree `pv-agent/`, History aus dem
eigenständigen Repo erhalten): lokaler RAG-Agent für die österreichische
Personalverrechnung, der ausschließlich aus der kuratierten Wissensbasis
(`pv-agent/wissensbasis/`, Layer 2) antwortet. Der Service (FastAPI)
läuft als Docker-Stack auf dem GPU-Host; Odoo konsumiert ihn über
`addons/l10n_at_payroll_agent` (Plausibilitätsprüfung einer geplanten
Auszahlung via `/v1/ask` `mode=review`). Plan, Betrieb und Regeln:
`pv-agent/planung.md`, `pv-agent/docs/DOCKER.md`, `pv-agent/docs/API.md`
und `.agents/skills/pv-rag-agent/SKILL.md`.
## 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`):
```sh
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).