fegger/odoo-at-payroll
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
1df5fb19c43bebedff91a120094e58f03c6a199f
odoo-at-payroll/personalverrechnung/PLAN-repo-split.md
T

16 KiB
Raw Blame History

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)

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

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

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.

Reference in New Issue View Git Blame Copy Permalink