296 lines
16 KiB
Markdown
296 lines
16 KiB
Markdown
# PLAN — Repo-Split Personalverrechnung (gem360 → eigenes Repo)
|
||
|
||
**Status:** Plan zur Freigabe (AGENTS.md-Workflow) — keine Ausführung vor
|
||
ausdrücklicher Freigabe. Dieser Plan beschreibt nur die Migration; es werden
|
||
bis zur Freigabe keine Dateien verschoben, umbenannt oder gelöscht.
|
||
|
||
- **Datum:** 2026-09-09
|
||
- **Basis:** Branch `dev-payroll` @ `d4e6763` (lokal, unpushed) über
|
||
Merge-Base `975277a` (origin/dev); 12 Commits
|
||
- **Verifikationen (2026-09-09):** `git log origin/dev..dev-payroll`,
|
||
Modul-Inspektion (~2.500 LOC, grep `vrv2015|budget_position_id|vrv_ansatz`
|
||
→ **0 Treffer**), Regelparameter-Inventar (`at_sv_*` vs. `gembg_*`),
|
||
Modell-Inventar, Deployment-Layout (`../ixsol`: `odoo`, `l10n_at_vrv2015`,
|
||
`l10n_at_vrv2015_glm`, `gem360` als separate Addon-Quellen)
|
||
- **Kontext:** `personalverrechnung/PLAN-payroll-bgld.md` (Abschnitte 4, 7),
|
||
Diskussion General-AT-Payroll 2026-09-09 (Zusatzschätzung ~135–190 PT)
|
||
|
||
## 1. Ziel & Motivation
|
||
|
||
Die österreichische Personalverrechnung wird aus `gem360-git` in ein eigenes
|
||
Projekt/Git-Repo überführt und dort weiterentwickelt — zunächst die Bgld.
|
||
Gemeinde-Personalverrechnung (laufender Auftrag, AP3+ offen), perspektivisch
|
||
ein General-AT-Payroll-Produkt (KV-basierte Privatwirtschaft) auf
|
||
gemeinsamem Bundes-Kern.
|
||
|
||
Begründung:
|
||
|
||
- **Abhängigkeitspfeil bleibt einseitig gem360 → Payroll-Repo** (späteres
|
||
Bridge-Modul); Payroll hängt niemals von gem360-Modulen ab.
|
||
- **Bundes-Kern (LSt, SV, Meldewesen) entsteht als eigenes Modul** und wird
|
||
von Gemeinde- UND General-Produkt konsumiert → jährliche Rechtswerte
|
||
(LSt-Tarif, SV-Sätze, ELDA/FinOnl-Specs) werden einmal gepflegt, nie
|
||
geforkt.
|
||
- **Timing:** ~2.500 LOC, AP3 (LSt) noch nicht gebaut, keine VRV-Verflechtung
|
||
(grep 0 Treffer, `l10n_at_vrv2015` steht nur als `depends`-Deklaration im
|
||
Manifest) → Split heute 2–4 PT; nach AP3/AP5 wären es 15–25+ PT.
|
||
- **Scope:** gem360 bleibt VRV/Gemeinde-Buchhaltung; das harte Constraint
|
||
„KEINE Lohnverrechnung in Odoo" aus `50-SCOPE-module.md` bleibt für gem360
|
||
gewahrt. Payroll wird eigene Produktlinie mit eigenem Release-Takt.
|
||
|
||
## 2. Ist-Zustand (verifiziert 2026-09-09)
|
||
|
||
| Element | Zustand |
|
||
|---|---|
|
||
| Branch `dev-payroll` | lokal, **unpushed**; 12 Commits: Plan-Docs (4), Modul (Scaffold, AP1, SV-TASY-Layer, AP2-Entgelt-Engine), Skills (2 Commits) |
|
||
| Modul `l10n_at_gemeinde_payroll` | v19.0.1.3.0, ~2.500 LOC / 25 Dateien; implementiert: AP1 Katalog (35 Gruppen/433 Werte 2026), AP2 Entgelt-Engine (Structure + Regeln), SV-Wertelayer (17 `at_sv_*`-Rule-Parameter 2026 aus ÖGK TASY + Import-Wizard) |
|
||
| Tests | 3 Suiten: `test_katalog`, `test_entgelt`, `test_tasy_import` |
|
||
| VRV-Verflechtung | **keine** — nur `depends`-Deklaration `l10n_at_vrv2015`; kein Code/Daten-Bezug (grep 0 Treffer); `l10n_at_vrv2015` selbst referenziert Payroll nicht (grep 0) |
|
||
| Regelparameter | `rule_parameters_2026.xml` = 17 sektor-neutrale `at_sv_*`-Parameter (KV/PV/UV/AV/AK/WF/BV/GfG/HBG/IESG) → Kern; `rule_parameters_entgelt.xml` = 4 `gembg_*`-Parameter (KIZU/Journaldienst/SFZU/Bereitschaft) → GemBG |
|
||
| Modelle | Kern-Kandidaten: `gemeinde.payroll.tasy.mapping/.import.line/.import.wizard` (tasy.py); GemBG-seitig: `gemeinde.payroll.entlohnungsgruppe/-stufe`, `vorrueckung.wizard`, `hr.version`/`hr.employee`-Erweiterungen |
|
||
| Manifest | `depends: [hr_payroll, hr_payroll_account, l10n_at_vrv2015]`; **Beschreibung veraltet** (nennt nur AP1+SV-Layer, AP2 fehlt) |
|
||
| Skills | `.agents/skills/` seit `83250b8` versioniert; Commit `7f99677` tracked **alle** Skills + `IMPORT_ROLLBACK_NOTES.md` auch auf dev-payroll (inkl. vrv2015-Skill mit PDF-Assets) → beim Import beachten |
|
||
| `.firecrawl/` | unversionierte Rechts-Rohquellen (GemBG-Konsolidierung, RV 0715, SV-Werte 2026) → **manuell kopieren**, sonst erzwingt der payroll-Skill Re-Fetch von RIS/sozialversicherung.at |
|
||
| Werkzeuge | `git filter-repo` **nicht installiert** (pip nachinstallierbar); Workingtree von dev-payroll ist clean (nur Untracked) |
|
||
|
||
## 3. Ziel-Struktur
|
||
|
||
### 3.1 Neues Repo (Name: Entscheidung D1, Vorschlag `odoo-at-payroll`)
|
||
|
||
```
|
||
odoo-at-payroll/
|
||
AGENTS.md # angepasster Projekt-Workflow (committen!)
|
||
.agents/skills/
|
||
payroll/SKILL.md # kopiert + Pfade angepasst
|
||
odoo19-development/SKILL.md # kopiert (gem360-Variante ist generisch)
|
||
agent-memory/SKILL.md # kopiert; eigenes .agents/MEMORY.md frisch
|
||
.agents/MEMORY.md # neu aufgesetzt (Handoff für Payroll-Repo)
|
||
addons/
|
||
l10n_at_hr_payroll/ # KERN: SV-Werte + TASY (heute), LSt (AP3),
|
||
# Meldewesen (AP5), Belege (AP6),
|
||
# Jahreswerte (AP8-LSt/SV-Teil)
|
||
l10n_at_gemeinde_payroll/ # hierher migriert; Katalog + GemBG-Regeln;
|
||
# depends: l10n_at_hr_payroll (statt vrv2015)
|
||
l10n_at_hr_payroll_private/ # SPÄTER: General-AT (KV-Framework, AZG/UrlG,
|
||
# 13./14. Bezüge, Abfertigung Neu); nur Gerüst
|
||
personalverrechnung/ # komplett übernommen (Docs, tools/, quellen/)
|
||
.firecrawl/ # manuell kopiert (unversioniert, lokal)
|
||
docs/ # CHANGELOG, Testing-Strategie (anlegen)
|
||
```
|
||
|
||
### 3.2 Modul-Split (Abhängigkeiten)
|
||
|
||
| Modul | depends | Inhalt |
|
||
|---|---|---|
|
||
| `l10n_at_hr_payroll` (neu, Kern) | `hr_payroll` | `hr.rule.parameter`-Seeds `at_sv_*` (rule_parameters_2026.xml), TASY-Modelle + Mapping-Daten + Import-Wizard + Views, `test_tasy_import`; später: `lohnsteuer.py`-Utility (AP3), L16/eSV-Exporte (AP5), Belege (AP6) |
|
||
| `l10n_at_gemeinde_payroll` (migriert) | `l10n_at_hr_payroll`, `hr_payroll_account` | Katalog (entlohnung.py, CSVs), `hr.version`/`hr.employee`-Felder, Vorrückungs-Wizard, Structure + Entgelt-Regeln (referenzieren `at_sv_*`-Parameter **per Code** → funktionieren unverändert, solange Kern installiert ist), `rule_parameters_entgelt.xml`, Tests `test_katalog`/`test_entgelt` |
|
||
| `l10n_at_hr_payroll_private` (später) | `l10n_at_hr_payroll` | General-AT-Produkt (eigener Plan, ~125–175 PT) |
|
||
| `l10n_at_gemeinde_payroll_vrv` (Bridge, **bleibt in gem360**) | `l10n_at_gemeinde_payroll`, `l10n_at_vrv2015` | AP7-Inhalt: `vrv_ansatz_id` auf `hr.salary.rule`, Posting-Hook `_prepare_line_values` (Ansatz/EHH/FHH), Abfertigungsrückstellungs-Buchung. **Jetzt nicht bauen** — nur der Vertrag (Abschnitt 6) |
|
||
|
||
Regel-Parameter-Auflösung: die GemBG-Regeln lesen Parameter über
|
||
`payslip._rule_parameter('at_sv_kv_dg')` (String-Code, kein XML-ID-Bezug);
|
||
die Verschiebung der Parameter-Daten in den Kern erfordert **keine**
|
||
Regeländerung.
|
||
|
||
## 4. Migrationsschritte (konkret)
|
||
|
||
### 4.1 M1 — Backup (Voraussetzung, zuerst)
|
||
|
||
```bash
|
||
cd /home/fegger/Code/ixsol/gem360-git
|
||
git push origin dev-payroll # existiert bisher nur lokal!
|
||
```
|
||
|
||
Außerdem: `.firecrawl/` sichern (unversioniert) und dieser Plan
|
||
(`personalverrechnung/PLAN-repo-split.md`) wird **vor dem Export auf
|
||
dev-payroll committet**, damit er mit der Historie wandert.
|
||
|
||
### 4.2 M2 — Repo-Bootstrap
|
||
|
||
- Remote steht (D1 entschieden 2026-09-09, Existenz verifiziert — Repo
|
||
ist leer):
|
||
`http://100.103.83.12:3003/fegger/odoo-at-payroll.git`;
|
||
Clone nach `/home/fegger/Code/ixsol/odoo-at-payroll`.
|
||
- Odoo-19-Enterprise-Source als Geschwister-Checkout (Precedent:
|
||
`/home/fegger/Code/ixsol/odoo`); Odoo-Version-Pin im README dokumentieren.
|
||
- Grundgerüst: `addons/`, `personalverrechnung/`, `docs/`, `.agents/`;
|
||
saubere `.gitignore` (kein Nachbau der gem360-`.git/info/exclude`-Lösung).
|
||
- AGENTS.md **wirklich committen** (war in gem360 lokal excluded).
|
||
|
||
### 4.3 M3 — History-Import
|
||
|
||
**Option B (empfohlen — saubere, pfad-begrenzte Historie):**
|
||
|
||
```bash
|
||
pip install git-filter-repo # einmalig
|
||
cd /tmp
|
||
git clone /home/fegger/Code/ixsol/gem360-git gem360-payroll-export
|
||
cd gem360-payroll-export
|
||
git checkout dev-payroll
|
||
git filter-repo --path 60-PLAN-payroll-bgld.md \
|
||
--path personalverrechnung \
|
||
--path addons/l10n_at_gemeinde_payroll
|
||
# Ergebnis: die 10 Payroll-Commits (+ ggf. der Plan-Commit aus M1 = 11);
|
||
# die Skill-Commits (7f99677, e4e8200) entfallen automatisch
|
||
# (betreffen keine der Pfade)
|
||
git branch -m dev-payroll main
|
||
git remote add origin http://100.103.83.12:3003/fegger/odoo-at-payroll.git
|
||
git push -u origin main
|
||
```
|
||
|
||
Provenance (RV 0715-Werte, TASY-Quellen, Plan-Historie) bleibt im
|
||
Commit-Log erhalten.
|
||
|
||
**Option A (Fallback, keine Zusatz-Tools):**
|
||
|
||
```bash
|
||
cd /home/fegger/Code/ixsol/gem360-git
|
||
git format-patch 975277a..dev-payroll -o /tmp/payroll-patches
|
||
# im neuen Repo:
|
||
git am /tmp/payroll-patches/*.patch
|
||
# danach Aufräum-Commit: entfernen von .agents/skills/{vrv2015,
|
||
# accounting-review, odoo19-accounting} und IMPORT_ROLLBACK_NOTES.md
|
||
# (gem360-spezifisch, mit Option A in der Historie enthalten)
|
||
```
|
||
|
||
Nach beiden Optionen: `personalverrechnung/quellen/TASY-LSWH-Export-20260324.xml`
|
||
(93k Zeilen) prüfen — wandert mit, ggf. per `.gitignore` von dauerhafter
|
||
Versionierung ausnehmen (Precedent-Entscheidung im neuen Repo).
|
||
|
||
### 4.4 M4 — Modul-Split Kern/Gemeinde
|
||
|
||
1. `addons/l10n_at_hr_payroll/` anlegen (Manifest v19.0.1.0.0,
|
||
`depends: [hr_payroll]`, LGPL-3, `countries: ['at']`).
|
||
2. **Verschieben** in den Kern: `models/tasy.py`, `views/tasy_views.xml`,
|
||
`data/tasy_mapping.xml`, `data/rule_parameters_2026.xml`,
|
||
`tests/test_tasy_import.py`, Security-Zeilen 6–9 aus
|
||
`ir.model.access.csv` (eigene CSV im Kern).
|
||
3. **Verbleibend** in `l10n_at_gemeinde_payroll`: alles GemBG-seitige
|
||
(Katalog, hr.version-Felder, Vorrückungs-Wizard, Structure, Entgelt-
|
||
Regeln, `rule_parameters_entgelt.xml`, `test_katalog`, `test_entgelt`,
|
||
restliche Security-Zeilen).
|
||
4. `depends` der Gemeinde-Moduls: `l10n_at_vrv2015` **streichen**, durch
|
||
`l10n_at_hr_payroll` ersetzen (`hr_payroll_account` bleibt).
|
||
5. **Model-Rename (D5, empfohlen):** `gemeinde.payroll.tasy.mapping`,
|
||
`.import.line`, `.import.wizard` → `l10n.at.payroll.tasy.mapping` usw.,
|
||
inkl. XML-IDs in Views/Mapping-Daten/Security/Tests. **Jetzt billiger
|
||
denn je** (noch keine Datenbank mit dem Modul); später kostet ein Odoo-
|
||
Modell-Rename xmlid-Migration. Alternativ: Namen belassen und im Kern
|
||
dokumentieren (unschön, funktioniert).
|
||
6. Manifest-Beschreibung von `l10n_at_gemeinde_payroll` korrigieren
|
||
(AP2-Entgelt-Engine ist implementiert; aktueller Text ist veraltet).
|
||
7. `l10n_at_hr_payroll_private/` nur als leeres Gerüst mit README
|
||
(„folgt; siehe personalverrechnung/") — kein Code.
|
||
|
||
### 4.5 M5 — Skills / AGENTS / Memory im neuen Repo
|
||
|
||
- `payroll/SKILL.md` kopieren + Pfade anpassen: `personalverrechnung/`- und
|
||
`addons/`-Pfade gelten unverändert; VRV-Referenzen (Buchungsabschnitt)
|
||
auf die **künftige Bridge** in gem360 umlenken; YAML-Frontmatter
|
||
beachten (Projektkonvention: name = Verzeichnisname, description).
|
||
- `odoo19-development`, `agent-memory` kopieren; neues `.agents/MEMORY.md`
|
||
aufsetzen (Fokus: Migration abgeschlossen, AP3 als nächster Schritt).
|
||
- Neues `AGENTS.md`: gem360-Workflow übernehmen, VRV-Skill-Selection und
|
||
50-SCOPE-Bezüge entfernen.
|
||
|
||
### 4.6 M6 — gem360-Seite
|
||
|
||
- `.agents/skills/payroll/` in gem360 auf **Stub** reduzieren (Verweis auf
|
||
das Payroll-Repo; die Weiterentwicklung läuft dort) — D3.
|
||
- `.agents/MEMORY.md`: Handoff-Eintrag (Split durchgeführt, dev-payroll
|
||
obsolet, AP3 läuft im neuen Repo).
|
||
- **Branch `dev-payroll` in gem360 vorerst behalten** (Nutzer-Entscheidung
|
||
2026-09-09: „keep dev-payroll for now“) — Stilllegung (löschen oder als
|
||
`archive/dev-payroll` taggen) auf später vertagt. Bis dahin gilt:
|
||
keine weitere Payroll-Implementierung auf dem gem360-Branch und
|
||
**kein Merge nach dev/va_module** (sonst Dopplung mit dem Payroll-Repo).
|
||
- `50-SCOPE-module.md`/Backlog: Pointer auf das Payroll-Repo ergänzen
|
||
(Scope-Constraint bleibt erfüllt; Gemeinde-Payroll läuft extern weiter).
|
||
- Deployment-Wiring (D4): Precedent nutzen — pro Deployment gepinntes
|
||
Checkout `<deploy>/odoo-at-payroll/addons` als zusätzliche addons_path-
|
||
Quelle (wie `l10n_at_vrv2015` als Geschwister-Verzeichnis). Alternativen:
|
||
git submodule vs. deploy-Artifact. Erst relevant, sobald die Bridge bzw.
|
||
die erste Payroll-Installation auf einem gem360-Deployment liegt.
|
||
|
||
### 4.7 M7 — Validierung
|
||
|
||
- `py_compile` über beide Module; XML-Well-formedness-Check (Muster wie im
|
||
va_module-Workflow).
|
||
- Odoo-Testlauf auf **Wegwerf-DB** (nie direkt auf `gem360_dev`):
|
||
`-i l10n_at_hr_payroll,l10n_at_gemeinde_payroll
|
||
--test-tags /l10n_at_hr_payroll,/l10n_at_gemeinde_payroll` —
|
||
alle 3 Suiten grün (Katalog, Entgelt, TASY-Import).
|
||
- Installations-Prüfung ohne `l10n_at_vrv2015` im addons_path (beweist die
|
||
entkoppelte depends-Kette).
|
||
- gem360-Seite: grep, dass kein gem360-Code/Daten das Payroll-Modul
|
||
referenzieren (erwartet: 0 Treffer — verifiziert), und
|
||
Install-Regression der VRV-Module (unverändert).
|
||
|
||
## 5. Aufwandsschätzung
|
||
|
||
| M | Schritt | PT |
|
||
|---|---|---|
|
||
| M1 | Backup (Push, Plan-Commit, .firecrawl-Sicherung) | 0,5 |
|
||
| M2 | Repo-Bootstrap (GitLab, Struktur, Odoo-Pin, AGENTS) | 2–3 |
|
||
| M3 | History-Import (Option B; inkl. pip install / alternativ A + Aufräum) | 1–2 |
|
||
| M4 | Modul-Split Kern/Gemeinde, depends, Manifest-Text | 2–4 |
|
||
| — | Model-Rename TASY (D5, falls ja) | +1 |
|
||
| M5 | Skills/AGENTS/Memory im neuen Repo | 1–2 |
|
||
| M6 | gem360-Seite (Stub, MEMORY, Branch-Ruhestand, Scope-Pointer) | 1–2 |
|
||
| M7 | Validierung beider Seiten | 1–2 |
|
||
| **Σ** | | **9–17 PT ≈ 1,5–2,5 Wochen** |
|
||
|
||
Danach unverändert weiter: AP0/AP3+ des Bgld.-Auftrags (~165 PT Rest)
|
||
— aber AP3 (Lohnsteuer) **im Kern-Modul** des neuen Repos, sodass das
|
||
General-Produkt ihn erbt. Zusatzschätzung General-AT dort: ~125–175 PT.
|
||
|
||
## 6. Versions-/Kompatibilitätsvertrag (Bridge)
|
||
|
||
- Das Payroll-Repo taggt Releases (Vorschlag: `payroll-<modulversion>` je
|
||
Modul-Bundle, beginnend `payroll-19.0.1.0`).
|
||
- gem360-Deployments pinnen ein Tag; die Bridge
|
||
`l10n_at_gemeinde_payroll_vrv` dokumentiert die getestete Kombination
|
||
(Odoo hat keinen nativen Versions-Range-Mechanismus für `depends` →
|
||
Vertrag per CHANGELOG + Install-Validierung im Deployment).
|
||
- Regel: Payroll-Repo hängt **nie** von gem360-Modulen ab; die Bridge hängt
|
||
von beiden Seiten ab und ist die einzige Nahtstelle.
|
||
- Odoo-Major-Upgrades künftig in beiden Repos gegen denselben Odoo-Pin
|
||
validieren.
|
||
|
||
## 7. Risiken
|
||
|
||
| Risiko | Gegenmaßnahme |
|
||
|---|---|
|
||
| `dev-payroll` unpushed → Totalverlust bei Migration-Fehlern | M1 zuerst; erst nach erfolgreichem Import Branch stilllegen |
|
||
| Commit `7f99677` zieht gem360-Skills (vrv2015-PDFs, Rollback-Notes) in die History | Option B (pfad-gefiltert) primär; bei Option A Aufräum-Commit |
|
||
| `.firecrawl/` unversioniert → Provenance-Verlust | manueller Copy in M2; payroll-Skill erzwingt sonst Re-Fetch |
|
||
| AGENTS.md/Skills nur lokal getrackt (gem360-Exclude-Besonderheit) | im neuen Repo bewusst committen; YAML-Frontmatter-Konvention einhalten |
|
||
| Doppelte Odoo-Version-Pflege (zwei Repos) | gemeinsamer Odoo-Pin + Vertrag nach Abschnitt 6 |
|
||
| Unterwart-Deployment braucht künftig zwei Addon-Quellen | D4 mit Ops klären, bevor die Bridge (AP7) gebaut wird |
|
||
| TASY-Model-Rename später teuer (xmlid-Migration) | D5 jetzt entscheiden (empfohlen: ja, in M4) |
|
||
| Split-Fehler bei Security-CSV/XML-IDs | M7-Validierung (Install + alle Testsuiten) |
|
||
|
||
## 8. Offene Entscheidungen (vor M2 zu treffen)
|
||
|
||
| # | Entscheidung | Vorschlag |
|
||
|---|---|---|
|
||
| D1 | ~~Repo-Name & Hosting~~ | **Entschieden (2026-09-09):** `http://100.103.83.12:3003/fegger/odoo-at-payroll.git` (verifiziert: erreichbar, leer). Branch wird im neuen Repo zu `main` umbenannt. gem360-Branch `dev-payroll` bleibt vorerst (M6) |
|
||
| D2 | Kern-Modulname | `l10n_at_hr_payroll` (Upstream-konventionsgerecht; Name ist unsere Wahl, es existiert kein gleichnamiges Odoo-Modul) |
|
||
| D3 | Payroll-Skill in gem360 | Stub mit Verweis behalten (Bridge-Arbeit braucht Kontext) |
|
||
| D4 | Deployment-Mechanik | gepinntes Checkout als addons_path-Quelle (Precedent vrv2015-Geschwister) |
|
||
| D5 | TASY-Model-Rename jetzt? | ja (in M4; später deutlich teurer) |
|
||
| D6 | Lizenz | LGPL-3 wie bisher (nötig für möglichen späteren Upstream-Beitrag) |
|
||
|
||
## 9. Reihenfolge / Milestones
|
||
|
||
M0 Freigabe dieses Plans → M1 Backup → M2 Bootstrap → M3 Import →
|
||
M4 Modul-Split (inkl. D5) → M5 Skills/AGENTS/Memory → M6 gem360-Seite →
|
||
M7 Validierung → **AP0/AP3 (Lohnsteuer) im Kern-Modul des neuen Repos**
|
||
(gemäß `IMPLEMENTIERUNGSPLAN-Bgld.md`, Abschnitt 4.2 Regel `LSTL`).
|
||
|
||
## 10. Freigabe-Antrag
|
||
|
||
Mit Freigabe dieses Plans startet die Ausführung mit M1 (Backup) und M2
|
||
(Bootstrap). Optionen/Entscheidungen D1–D6 sind dabei je explizit zu
|
||
bestätigen; Abweichungen vom Plan (z. B. doch Option A beim Import)
|
||
erfolgen als Change-Request. |