[ADD] odoo-at-payroll: repo bootstrap (AGENTS, skills, README, CHANGELOG, private skeleton)
This commit is contained in:
@@ -0,0 +1,56 @@
|
|||||||
|
# Agent Memory — odoo-at-payroll
|
||||||
|
|
||||||
|
## Current focus
|
||||||
|
|
||||||
|
**Repo-Split aus gem360 abgeschlossen** (2026-09-09): Kern-Modul
|
||||||
|
`l10n_at_hr_payroll` (SV-Werte 2026, TASY-Import) + `l10n_at_gemeinde_payroll`
|
||||||
|
(AP1 Katalog, AP2 Entgelt-Engine) migriert; siehe `docs/CHANGELOG.md` und
|
||||||
|
`personalverrechnung/PLAN-repo-split.md`. Nächster Schritt: **AP3 (Lohnsteuer)
|
||||||
|
im Kern-Modul** gemäß `personalverrechnung/IMPLEMENTIERUNGSPLAN-Bgld.md`
|
||||||
|
(Abschnitt 4.2, Regel `LSTL`) — Implementierungsplan wartet weiterhin auf
|
||||||
|
die Freigaben des Bgld.-Auftrags (AP0 zuerst).
|
||||||
|
|
||||||
|
## Completed
|
||||||
|
|
||||||
|
- **Migration gem360 → odoo-at-payroll** (2026-09-09): dev-payroll nach
|
||||||
|
origin gepusht (Backup), History-Import per `git filter-repo`
|
||||||
|
(Branch hier: `main`), Modul-Split (TASY/SV-Layer in den Kern),
|
||||||
|
Model-Rename `l10n.at.payroll.tasy.*`, Skills/AGENTS/MEMORY neu
|
||||||
|
aufgesetzt, Manifest-Beschreibung auf AP1+AP2-Stand korrigiert.
|
||||||
|
- Vorher (aus gem360-Historie): AP1 Katalogmodell (35 Gruppen/433 Werte
|
||||||
|
2026), AP2 Entgelt-Engine (13 Regeln, Structure GEMBG.BGLD), SV-Werte
|
||||||
|
aus ÖGK TASY-LSWH; 3 Testsuiten (Katalog, Entgelt, TASY-Import).
|
||||||
|
|
||||||
|
## Open issues / blockers
|
||||||
|
|
||||||
|
- gem360-seitig gilt: Branch `dev-payroll` dort vorerst erhalten, aber
|
||||||
|
**keine Payroll-Implementierung mehr in gem360** und kein Merge nach
|
||||||
|
dev/va_module (Guardrails im gem360-Handoff). Die Brücke
|
||||||
|
`l10n_at_gemeinde_payroll_vrv` (AP7) wird in gem360 gegen getaggte
|
||||||
|
Releases dieses Repos gebaut.
|
||||||
|
- Bgld.-Auftrag: AP0 offen (Bestandsaufnahme Pilotmandant, ELDA/FinOnl-
|
||||||
|
Specs, VRV-Buchungsmatrix, offene RIS-Verifikationen) —
|
||||||
|
`IMPLEMENTIERUNGSPLAN-Bgld.md` Abschnitt 8.
|
||||||
|
- Odoo-Upgrades künftig in beiden Repos (gem360 + dieses) gegen denselben
|
||||||
|
Odoo-Pin validieren.
|
||||||
|
|
||||||
|
## Decisions & conventions
|
||||||
|
|
||||||
|
- SKILL.md braucht YAML-Frontmatter (name = Verzeichnisname, description,
|
||||||
|
disable-model-invocation).
|
||||||
|
- Abhängigkeitsrichtung: gem360 → dieses Repo (nur die Brücke hängt an
|
||||||
|
beiden), nie umgekehrt.
|
||||||
|
- Tests nur auf Wegwerf-DB (nie `gem360_dev`); je Änderung py_compile +
|
||||||
|
XML-Well-formedness-Check.
|
||||||
|
- `.firecrawl/` bleibt lokal unversioniert (Rechts-Rohquellen); bei Fehlen
|
||||||
|
neu beschaffen — niemals aus Trainingswerten arbeiten.
|
||||||
|
|
||||||
|
## Files that matter right now
|
||||||
|
|
||||||
|
- `personalverrechnung/PLAN-repo-split.md` — Migration (abgeschlossen)
|
||||||
|
- `personalverrechnung/IMPLEMENTIERUNGSPLAN-Bgld.md` — AP3+ (Freigabe-Gate)
|
||||||
|
- `personalverrechnung/RECHTSQUELLEN-Bgld.md` — verbindliche Rechtslage
|
||||||
|
- `personalverrechnung/ANGEBOTS-KALKULATION-Bgld-Personalverrechnung.md` —
|
||||||
|
AP-Rahmen, Prämissen P1–P10
|
||||||
|
- `addons/l10n_at_hr_payroll/` — Kern (SV/TASY; AP3 landet hier)
|
||||||
|
- `addons/l10n_at_gemeinde_payroll/` — GemBG (AP1+AP2)
|
||||||
@@ -0,0 +1,50 @@
|
|||||||
|
---
|
||||||
|
name: agent-memory
|
||||||
|
description: |
|
||||||
|
Persistent handoff memory for multi-session agent work on the
|
||||||
|
odoo-at-payroll project. Read this skill at the start of every new agent
|
||||||
|
conversation so the current thread can bootstrap context from the
|
||||||
|
repository rather than from chat history.
|
||||||
|
disable-model-invocation: false
|
||||||
|
---
|
||||||
|
|
||||||
|
## Always read at the start of a new conversation
|
||||||
|
|
||||||
|
1. `AGENTS.md` — mandatory project workflow.
|
||||||
|
2. This skill (`agent-memory/SKILL.md`).
|
||||||
|
3. `.agents/MEMORY.md` — current handoff log.
|
||||||
|
4. All other skills applicable to the task (see `AGENTS.md` skill
|
||||||
|
selection).
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
Zed agent threads do not share conversation history. This project therefore
|
||||||
|
keeps the shared state in the repository itself:
|
||||||
|
|
||||||
|
- `.agents/MEMORY.md` — rolling handoff log: current focus, completed work,
|
||||||
|
open blockers, decisions, files that matter.
|
||||||
|
- `<domain>/RUNBOOK.md` — operational memory for recurring workflows
|
||||||
|
(imports, validation, deployment).
|
||||||
|
|
||||||
|
Both files are ordinary markdown under git, so their history is preserved.
|
||||||
|
|
||||||
|
## After significant work
|
||||||
|
|
||||||
|
Update `.agents/MEMORY.md`:
|
||||||
|
|
||||||
|
- **Current focus**: one-line summary of what the thread was working on.
|
||||||
|
- **Completed**: concrete outcomes, file paths, commits.
|
||||||
|
- **Open issues / blockers**: anything unresolved at the end of the thread.
|
||||||
|
- **Decisions & conventions**: choices that future threads must respect.
|
||||||
|
- **Files that matter right now**: paths the next thread should read first.
|
||||||
|
|
||||||
|
Update a domain `RUNBOOK.md` when the task reveals a reusable observation:
|
||||||
|
|
||||||
|
- non-obvious mappings or workarounds;
|
||||||
|
- validation steps that caught errors;
|
||||||
|
- commands or snippets that should be reused.
|
||||||
|
|
||||||
|
## When starting a new thread
|
||||||
|
|
||||||
|
Paste a brief handoff if helpful, but **do not rely on it**. Always verify
|
||||||
|
the actual current state from the memory files, git log, and the relevant code.
|
||||||
@@ -0,0 +1,130 @@
|
|||||||
|
---
|
||||||
|
name: odoo19-development
|
||||||
|
description: |
|
||||||
|
Guidance for developing and maintaining Odoo 19 Enterprise modules.
|
||||||
|
disable-model-invocation: false
|
||||||
|
---
|
||||||
|
|
||||||
|
## Required source material
|
||||||
|
|
||||||
|
Before implementation, consult:
|
||||||
|
|
||||||
|
- Odoo 19 source available in the repository/environment;
|
||||||
|
- Odoo 19 development coding guidelines;
|
||||||
|
- Odoo 19 Git guidelines;
|
||||||
|
- existing implementations of the functionality being changed.
|
||||||
|
|
||||||
|
Do not rely solely on knowledge from other Odoo versions.
|
||||||
|
|
||||||
|
## Framework-first development
|
||||||
|
|
||||||
|
Odoo already provides extensive infrastructure. Before writing custom code,
|
||||||
|
search for an existing implementation.
|
||||||
|
|
||||||
|
Look for:
|
||||||
|
|
||||||
|
- existing models;
|
||||||
|
- inherited models;
|
||||||
|
- mixins;
|
||||||
|
- computed fields;
|
||||||
|
- constraints;
|
||||||
|
- ORM helpers;
|
||||||
|
- views;
|
||||||
|
- actions;
|
||||||
|
- security mechanisms;
|
||||||
|
- `account.report` infrastructure;
|
||||||
|
- existing localization patterns;
|
||||||
|
- standard accounting functionality.
|
||||||
|
|
||||||
|
Extend or compose existing functionality whenever practical.
|
||||||
|
|
||||||
|
Avoid:
|
||||||
|
|
||||||
|
- monkey patching;
|
||||||
|
- duplicating standard Odoo functionality;
|
||||||
|
- unnecessary overrides;
|
||||||
|
- custom infrastructure where an Odoo mechanism exists;
|
||||||
|
- version-specific APIs copied from older Odoo releases.
|
||||||
|
|
||||||
|
## API verification
|
||||||
|
|
||||||
|
Every referenced API must be verified.
|
||||||
|
|
||||||
|
Before using a model, field, method, XML ID, module, package, or framework API:
|
||||||
|
|
||||||
|
1. search the current Odoo 19 source;
|
||||||
|
2. verify the exact name and signature/behavior;
|
||||||
|
3. inspect callers or existing implementations where useful;
|
||||||
|
4. only then use it.
|
||||||
|
|
||||||
|
Never invent plausible Odoo APIs or Python dependencies.
|
||||||
|
|
||||||
|
## Repository exploration
|
||||||
|
|
||||||
|
Use search strategically.
|
||||||
|
|
||||||
|
For an unfamiliar feature:
|
||||||
|
|
||||||
|
1. find the relevant model;
|
||||||
|
2. find existing implementations;
|
||||||
|
3. inspect inheritance;
|
||||||
|
4. inspect views/actions/security;
|
||||||
|
5. inspect tests;
|
||||||
|
6. identify the smallest appropriate extension point.
|
||||||
|
|
||||||
|
Do not start implementation immediately after finding the first apparently
|
||||||
|
relevant file.
|
||||||
|
|
||||||
|
## Odoo conventions
|
||||||
|
|
||||||
|
Follow the project's Odoo 19 coding guidelines.
|
||||||
|
|
||||||
|
Prefer:
|
||||||
|
|
||||||
|
- ORM operations;
|
||||||
|
- declarative fields and constraints;
|
||||||
|
- proper model inheritance;
|
||||||
|
- standard security mechanisms;
|
||||||
|
- standard views and actions;
|
||||||
|
- existing framework abstractions.
|
||||||
|
|
||||||
|
Avoid unnecessary SQL, low-level manipulation, and custom abstractions.
|
||||||
|
|
||||||
|
## Odoo 19 references
|
||||||
|
|
||||||
|
The following pinned Odoo 19 documentation is included with this skill:
|
||||||
|
|
||||||
|
- `references/coding_guidelines.rst`
|
||||||
|
- `references/git_guidelines.rst`
|
||||||
|
|
||||||
|
These documents are authoritative for Odoo coding and Git conventions in this
|
||||||
|
repository.
|
||||||
|
|
||||||
|
When a conflict exists between general knowledge and these references, follow
|
||||||
|
the pinned Odoo 19 references.
|
||||||
|
|
||||||
|
## Testing
|
||||||
|
|
||||||
|
Every functional change should have appropriate tests.
|
||||||
|
|
||||||
|
Tests should verify behavior rather than implementation details.
|
||||||
|
|
||||||
|
For accounting functionality, include relevant:
|
||||||
|
|
||||||
|
- company behavior;
|
||||||
|
- currency behavior;
|
||||||
|
- dates/fiscal periods;
|
||||||
|
- posted vs draft records;
|
||||||
|
- reconciliation;
|
||||||
|
- access rights;
|
||||||
|
- accounting edge cases.
|
||||||
|
|
||||||
|
## Maintainability
|
||||||
|
|
||||||
|
Optimize for long-term Odoo upgradeability.
|
||||||
|
|
||||||
|
Prefer small, idiomatic extensions over large replacements of standard behavior.
|
||||||
|
|
||||||
|
Avoid unrelated refactoring.
|
||||||
|
|
||||||
|
If standard functionality is intentionally not reused, document why.
|
||||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,145 @@
|
|||||||
|
==============
|
||||||
|
Git guidelines
|
||||||
|
==============
|
||||||
|
|
||||||
|
Configure your git
|
||||||
|
------------------
|
||||||
|
|
||||||
|
Based on ancestral experience and oral tradition, the following things go a long
|
||||||
|
way towards making your commits more helpful:
|
||||||
|
|
||||||
|
- Be sure to define both the user.email and user.name in your local git config
|
||||||
|
|
||||||
|
.. code-block:: text
|
||||||
|
|
||||||
|
git config --global <var> <value>
|
||||||
|
|
||||||
|
- Be sure to add your full name to your Github profile here. Please feel fancy
|
||||||
|
and add your team, avatar, your favorite quote, and whatnot ;-)
|
||||||
|
|
||||||
|
Commit message structure
|
||||||
|
------------------------
|
||||||
|
|
||||||
|
Commit message has four parts: tag, module, short description and full
|
||||||
|
description. Try to follow the preferred structure for your commit messages
|
||||||
|
|
||||||
|
.. code-block:: text
|
||||||
|
|
||||||
|
[TAG] module: describe your change in a short sentence (ideally < 50 chars)
|
||||||
|
|
||||||
|
Long version of the change description, including the rationale for the change,
|
||||||
|
or a summary of the feature being introduced.
|
||||||
|
|
||||||
|
Please spend a lot more time describing WHY the change is being done rather
|
||||||
|
than WHAT is being changed. This is usually easy to grasp by actually reading
|
||||||
|
the diff. WHAT should be explained only if there are technical choices
|
||||||
|
or decision involved. In that case explain WHY this decision was taken.
|
||||||
|
|
||||||
|
End the message with references, such as task or bug numbers, PR numbers, and
|
||||||
|
OPW tickets, following the suggested format:
|
||||||
|
task-123 (related to task)
|
||||||
|
Fixes #123 (close related issue on Github)
|
||||||
|
Closes #123 (close related PR on Github)
|
||||||
|
opw-123 (related to ticket)
|
||||||
|
|
||||||
|
Tag and module name
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
Tags are used to prefix your commit. They should be one of the following
|
||||||
|
|
||||||
|
- **[FIX]** for bug fixes: mostly used in stable version but also valid if you
|
||||||
|
are fixing a recent bug in development version;
|
||||||
|
- **[REF]** for refactoring: when a feature is heavily rewritten;
|
||||||
|
- **[ADD]** for adding new modules;
|
||||||
|
- **[REM]** for removing resources: removing dead code, removing views,
|
||||||
|
removing modules, ...;
|
||||||
|
- **[REV]** for reverting commits: if a commit causes issues or is not wanted
|
||||||
|
reverting it is done using this tag;
|
||||||
|
- **[MOV]** for moving files: use git move and do not change content of moved file
|
||||||
|
otherwise Git may loose track and history of the file; also used when moving
|
||||||
|
code from one file to another;
|
||||||
|
- **[REL]** for release commits: new major or minor stable versions;
|
||||||
|
- **[IMP]** for improvements: most of the changes done in development version
|
||||||
|
are incremental improvements not related to another tag;
|
||||||
|
- **[MERGE]** for merge commits: used in forward port of bug fixes but also as
|
||||||
|
main commit for feature involving several separated commits;
|
||||||
|
- **[CLA]** for signing the Odoo Individual Contributor License;
|
||||||
|
- **[I18N]** for changes in translation files;
|
||||||
|
- **[PERF]** for performance patches;
|
||||||
|
- **[CLN]** for code cleanup;
|
||||||
|
- **[LINT]** for linting passes;
|
||||||
|
|
||||||
|
After tag comes the modified module name. Use the technical name as functional
|
||||||
|
name may change with time. If several modules are modified, list them or use
|
||||||
|
various to tell it is cross-modules. Unless really required or easier avoid
|
||||||
|
modifying code across several modules in the same commit. Understanding module
|
||||||
|
history may become difficult.
|
||||||
|
|
||||||
|
Commit message header
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
After tag and module name comes a meaningful commit message header. It should be
|
||||||
|
self explanatory and include the reason behind the change. Do not use single words
|
||||||
|
like "bugfix" or "improvements". Try to limit the header length to about 50 characters
|
||||||
|
for readability.
|
||||||
|
|
||||||
|
Commit message header should make a valid sentence once concatenated with
|
||||||
|
``if applied, this commit will <header>``. For example ``[IMP] base: prevent to
|
||||||
|
archive users linked to active partners`` is correct as it makes a valid sentence
|
||||||
|
``if applied, this commit will prevent users to archive...``.
|
||||||
|
|
||||||
|
Commit message full description
|
||||||
|
-------------------------------
|
||||||
|
|
||||||
|
In the message description specify the part of the code impacted by your changes
|
||||||
|
(module name, lib, transversal object, ...) and a description of the changes.
|
||||||
|
|
||||||
|
First explain WHY you are modifying code. What is important if someone goes back
|
||||||
|
to your commit in about 4 decades (or 3 days) is why you did it. It is the
|
||||||
|
purpose of the change.
|
||||||
|
|
||||||
|
What you did can be found in the commit itself. If there was some technical choices
|
||||||
|
involved it is a good idea to explain it also in the commit message after the why.
|
||||||
|
For Odoo R&D developers "PO team asked me to do it" is not a valid why, by the way.
|
||||||
|
|
||||||
|
Please avoid commits which simultaneously impact multiple modules. Try to split
|
||||||
|
into different commits where impacted modules are different. It will be helpful
|
||||||
|
if we need to revert changes in a given module separately.
|
||||||
|
|
||||||
|
Don't hesitate to be a bit verbose. Most people will only see your commit message
|
||||||
|
and judge everything you did in your life just based on those few sentences.
|
||||||
|
No pressure at all.
|
||||||
|
|
||||||
|
**You spend several hours, days or weeks working on meaningful features. Take
|
||||||
|
some time to calm down and write clear and understandable commit messages.**
|
||||||
|
|
||||||
|
If you are an Odoo R&D developer the WHY should be the purpose of the task you
|
||||||
|
are working on. Full specifications make the core of the commit message.
|
||||||
|
**If you are working on a task that lacks purpose and specifications please
|
||||||
|
consider making them clear before continuing.**
|
||||||
|
|
||||||
|
Finally here are some examples of correct commit messages :
|
||||||
|
|
||||||
|
.. code-block:: text
|
||||||
|
|
||||||
|
[REF] models: use `parent_path` to implement parent_store
|
||||||
|
|
||||||
|
This replaces the former modified preorder tree traversal (MPTT) with the
|
||||||
|
fields `parent_left`/`parent_right`[...]
|
||||||
|
|
||||||
|
[FIX] account: remove frenglish
|
||||||
|
|
||||||
|
[...]
|
||||||
|
|
||||||
|
Closes #22793
|
||||||
|
Fixes #22769
|
||||||
|
|
||||||
|
[FIX] website: remove unused alert div, fixes look of input-group-btn
|
||||||
|
|
||||||
|
Bootstrap's CSS depends on the input-group-btn
|
||||||
|
element being the first/last child of its parent.
|
||||||
|
This was not the case because of the invisible
|
||||||
|
and useless alert.
|
||||||
|
|
||||||
|
.. note:: Use the long description to explain the *why* not the
|
||||||
|
*what*, the *what* can be seen in the diff
|
||||||
@@ -0,0 +1,151 @@
|
|||||||
|
---
|
||||||
|
name: payroll
|
||||||
|
description: |
|
||||||
|
Guidance for implementing Austrian payroll on the Odoo 19 hr_payroll
|
||||||
|
engine: Bgld. GemBG 2014 besoldung (Entlohnungsgruppen/-stufen,
|
||||||
|
quarterly Sonderzahlung), Lohnsteuer, SV/Dienstgeberbeitrag, the
|
||||||
|
shared AT core module l10n_at_hr_payroll, VRV account posting via the
|
||||||
|
gem360 bridge module l10n_at_gemeinde_payroll_vrv, L16/eSV
|
||||||
|
melde-dateien, annual Bezügeanpassung updates, and multi-Bundesland
|
||||||
|
extension. Use for any work on addons/l10n_at_hr_payroll,
|
||||||
|
addons/l10n_at_gemeinde_payroll or the legal foundations in
|
||||||
|
personalverrechnung/.
|
||||||
|
disable-model-invocation: false
|
||||||
|
---
|
||||||
|
|
||||||
|
## Applicability
|
||||||
|
|
||||||
|
Use this skill whenever work touches the Austrian payroll localization or
|
||||||
|
its foundations: the core module `addons/l10n_at_hr_payroll` (SV values,
|
||||||
|
TASY import, upcoming Lohnsteuer/Meldewesen/Belege), the municipal module
|
||||||
|
`addons/l10n_at_gemeinde_payroll` (Bgld. GemBG besoldung, payslip
|
||||||
|
structures/salary rules), Lohnsteuer, SV/DB contributions, payroll
|
||||||
|
reports and melde-dateien (L16, eSV/ELDA), annual value updates
|
||||||
|
(Bezügeanpassung), or extending the payroll to another Bundesland or to
|
||||||
|
the general private economy (`l10n_at_hr_payroll_private`).
|
||||||
|
|
||||||
|
Skills do not replace the mandatory `AGENTS.md` workflow. For payroll
|
||||||
|
work, combine this skill with:
|
||||||
|
|
||||||
|
- `odoo19-development/SKILL.md` (always);
|
||||||
|
- for GL posting / VRV work on the bridge module
|
||||||
|
`l10n_at_gemeinde_payroll_vrv` (which lives in the gem360 repository),
|
||||||
|
additionally consult the gem360 repo's `odoo19-accounting`, `vrv2015`
|
||||||
|
and `accounting-review` skills.
|
||||||
|
|
||||||
|
## Required project sources (read before planning)
|
||||||
|
|
||||||
|
1. `personalverrechnung/PLAN-payroll-bgld.md` — project frame, scope
|
||||||
|
variants, estimates and their revisions.
|
||||||
|
2. `personalverrechnung/RECHTSQUELLEN-Bgld.md` — the verified legal
|
||||||
|
inventory (status marks: ✅ verified / ⚠ plausible / ❓ open).
|
||||||
|
Treat these marks as binding: never code a ❓ value without
|
||||||
|
resolving it against a primary source first.
|
||||||
|
3. `personalverrechnung/ANGEBOTS-KALKULATION-Bgld-Personalverrechnung.md`
|
||||||
|
— approved scope (APs), Prämissen P1–P10, options and exclusions.
|
||||||
|
Changes that violate a Prämisse or an exclusion need explicit user
|
||||||
|
approval first.
|
||||||
|
4. Raw legal material (local, not versioned): `.firecrawl/` contains
|
||||||
|
the consolidated Bgld. GemBG 2014, GemBÜG 2014, the 2026
|
||||||
|
Bezügeanpassung tables (RV 0715), official SV-Werte 2026, and
|
||||||
|
ASVG/FLAG extracts. If `.firecrawl/` is missing, re-fetch from RIS
|
||||||
|
(ris.bka.gv.at) and sozialversicherung.at before working from
|
||||||
|
memory.
|
||||||
|
|
||||||
|
## Legal model (Burgenland — verified 2026-09)
|
||||||
|
|
||||||
|
- **One single legal source for the running payroll:** Bgld. GemBG 2014
|
||||||
|
(LGBl. Nr. 42/2014). All Gemeindebedienstete hold privatrechtliche
|
||||||
|
Dienstverhältnisse; no new öffentlich-rechtliche Dienstverhältnisse
|
||||||
|
(§ 1 Abs 3), no Kollektivvertrag, no AZG/UrlG/AngG/ATV references.
|
||||||
|
The GemBG itself governs Dienstzeit (40 h, § 33), Urlaub (28/33
|
||||||
|
Arbeitstage, §§ 92–94), Abfertigung (§ 130), Karenz (§§ 106 ff. with
|
||||||
|
Bgld. MVKG, LGBl. 16/2005).
|
||||||
|
- **Besoldung ab 1. 1. 2021** (IVa. Hauptstück, §§ 132 ff):
|
||||||
|
Entlohnungsgruppen, Entlohnungsstufen, Besoldungsdienstalter,
|
||||||
|
Vorrückungen; Zulagen incl. Kinderzulage (uncut for part-time),
|
||||||
|
Funktions-/Erschwernis-/Journaldienst-/Sonn-Feiertags-/Bereitschafts-
|
||||||
|
components (§§ 61–63, 74–87).
|
||||||
|
- **Sonderzahlung is quarterly:** 50 % of the Monatsentgelt (incl.
|
||||||
|
Kinderzulage) per Kalendervierteljahr — not a classic 13th/14th.
|
||||||
|
The lohnsteuerliche mapping to begünstigte Bezüge (§ 68 Abs 5/6 EStG)
|
||||||
|
is a designated open point (see below).
|
||||||
|
- **€ values come from annual Bgld. Bezügeanpassungs-Sammelgesetzen**
|
||||||
|
(tables in Anlagen/§-Ersetzungen; 2026: RV 0715/XXIII. GP / LGBl.
|
||||||
|
50/2026) — never from a KV catalog, never hard-coded from a prior
|
||||||
|
year.
|
||||||
|
- **Out of GemBG scope:** Lehrlinge (§ 1 Abs 2 Z 1), Gemeindeorgane
|
||||||
|
(Bürgermeisterbezüge per Gemeindegesetz/Bgm-PensionsG 1979), Freie
|
||||||
|
Städte Eisenstadt/Rust (Hauptstück VI Sonderregeln).
|
||||||
|
- **Federal law supplies:** EStG (§ 33 tariff, § 68 Pauschalbesteuerung,
|
||||||
|
§ 84 Lohnzettel/L16), LStR 2002 (findok), ASVG contributions and
|
||||||
|
limits (values: annual "Beitragsrechtliche Werte" PDF,
|
||||||
|
sozialversicherung.at), öffentlicher FLAF-Dienstgeberbeitrag
|
||||||
|
(§ 49a ASVG), KommStG exemption for the municipality's own employees,
|
||||||
|
Meldewesen (FinanzOnline, ELDA/eSV).
|
||||||
|
|
||||||
|
## Architecture rules
|
||||||
|
|
||||||
|
- Build strictly on the Odoo 19 `hr_payroll` engine: structures per
|
||||||
|
employee group, salary rules, rule parameters. No parallel engine,
|
||||||
|
no side tables for entitlements that the engine can express.
|
||||||
|
- **Shared federal core:** sector-neutral rules and values (Lohnsteuer,
|
||||||
|
SV/DB, Meldewesen, Belege, annual values) live in
|
||||||
|
`l10n_at_hr_payroll`; both the municipal module and the future
|
||||||
|
general product consume the core. Never fork core values.
|
||||||
|
- Annual and legal values (LSt tariff, SV rates, limits,
|
||||||
|
Bezügeanpassung tables) live in `hr.rule.parameter` data or
|
||||||
|
equivalent data files — never as literals inside rule code.
|
||||||
|
- Per-Bundesland separation from day one: katalog data, structures and
|
||||||
|
state-specific rules go into clearly separated data/models (Bgld.
|
||||||
|
first). A follow-up Bundesland must be expressible as data plus few
|
||||||
|
specific rules, not as a rewrite.
|
||||||
|
- GL posting via `hr_payroll_account` into VRV accounts (Anlage 3b
|
||||||
|
Klassen 4/5/6) with Ansatz/MVAG attribution happens **in the gem360
|
||||||
|
repository** via the bridge module `l10n_at_gemeinde_payroll_vrv`
|
||||||
|
(depends on this repo's `l10n_at_gemeinde_payroll` plus gem360's
|
||||||
|
`l10n_at_vrv2015`, EHH/FHH behaviour, provisions with
|
||||||
|
Rückstellungskonten and reconciliation anchors Anlage 1a/2a). This
|
||||||
|
repo stays free of any VRV dependency.
|
||||||
|
- Meldewesen is **file-based**: produce validated L16 (FinanzOnline)
|
||||||
|
and eSV/ELDA-XML export files plus Prüfprotokolle. Transmission,
|
||||||
|
certificates and Behördenkonten remain with the client or their tax
|
||||||
|
advisor (Prämisse P7) — do not build transmission infrastructure
|
||||||
|
without explicit approval.
|
||||||
|
|
||||||
|
## Verify before assuming (open points — resolve via RIS/findok)
|
||||||
|
|
||||||
|
- Öffentlicher FLAF-Dienstgeberbeitrag: exact current rate
|
||||||
|
§ 49a Abs 8/9 ASVG (historisch 4,5 %).
|
||||||
|
- KommStG 1993 § 6 (own employees exempt) — confirm the text.
|
||||||
|
- Bgld. MVKG full text (RIS-GesNr 20000326) for Karenz/MSchG details.
|
||||||
|
- Quartalsweise Sonderzahlung ↔ LSt begünstigte Bezüge (LStR 2002).
|
||||||
|
- Personalvertretungsumlage/AK-Umlage question for GemBG-Bedienstete;
|
||||||
|
Krankengeldumlage (§ 62 ASVG) for public employers; SV-Träger
|
||||||
|
confirmation (ÖGK Bgld.) from the client's payroll history.
|
||||||
|
|
||||||
|
Any further legal value must be taken from
|
||||||
|
`personalverrechnung/RECHTSQUELLEN-Bgld.md` or its named primary
|
||||||
|
sources (RIS, sozialversicherung.at, usp.gv.at, findok). If a value is
|
||||||
|
not verified there, stop and resolve it first — do not use training
|
||||||
|
knowledge for legal numbers.
|
||||||
|
|
||||||
|
## Annual change management (Wartung)
|
||||||
|
|
||||||
|
Each calendar year: fetch the new Bgld. Bezügeanpassung tables, the
|
||||||
|
SV-Werte PDF and LSt parameter changes; update rule-parameter data;
|
||||||
|
run the regression suite; document in `docs/CHANGELOG.md` and in
|
||||||
|
`personalverrechnung/` notes.
|
||||||
|
|
||||||
|
## Testing
|
||||||
|
|
||||||
|
- Rule-level unit tests for every GemBG, Lohnsteuer and SV component,
|
||||||
|
including Rechenfälle for Eckfälle: Ein-/Austritt im Monat,
|
||||||
|
Teilzeit/Herabsetzung, quartalsweise SZ, Geringfügigkeit, Karenz,
|
||||||
|
Jubiläumszuwendung, Über-/Mehrdienstleistung.
|
||||||
|
- Golden-Master against the client's reference runs as soon as they
|
||||||
|
exist (Angebotsphase: none available — see Prämissen P1/P10); the
|
||||||
|
contracted Parallellauf (2–3 months) is part of acceptance.
|
||||||
|
- Municipal GL posting tests live with the bridge in the gem360 repo
|
||||||
|
and must reconcile payroll postings against the Anlage-1a/2a engines
|
||||||
|
of `l10n_at_vrv2015` there.
|
||||||
@@ -0,0 +1,3 @@
|
|||||||
|
__pycache__/
|
||||||
|
*.pyc
|
||||||
|
.firecrawl/
|
||||||
@@ -0,0 +1,188 @@
|
|||||||
|
## Agent memory
|
||||||
|
|
||||||
|
Before starting work in a new agent conversation:
|
||||||
|
|
||||||
|
- read this `AGENTS.md`;
|
||||||
|
- read the `agent-memory/SKILL.md` skill;
|
||||||
|
- read `.agents/MEMORY.md` for the current project handoff.
|
||||||
|
|
||||||
|
Update `.agents/MEMORY.md` when the task produces significant state, blockers,
|
||||||
|
or decisions.
|
||||||
|
|
||||||
|
## Skills
|
||||||
|
|
||||||
|
Skills are task-specific instructions and must be read before planning work.
|
||||||
|
|
||||||
|
Before producing a plan, identify all skills applicable to the task and read
|
||||||
|
their `SKILL.md` files.
|
||||||
|
|
||||||
|
Skills are self-contained directories under `.agents/skills/`.
|
||||||
|
|
||||||
|
When a skill is selected, read its `SKILL.md` and consult any relevant
|
||||||
|
documentation under that skill's `references/` directory.
|
||||||
|
|
||||||
|
Skills are task-specific guidance, not a replacement for the mandatory
|
||||||
|
project workflow in this file. The agent must follow `AGENTS.md` even when
|
||||||
|
no skill applies.
|
||||||
|
|
||||||
|
### Skill selection
|
||||||
|
|
||||||
|
- Odoo/Python/module development:
|
||||||
|
`odoo19-development/SKILL.md`
|
||||||
|
- Any payroll work (besoldung, Lohnsteuer, SV, Meldewesen, annual value
|
||||||
|
updates, extending the modules in this repo):
|
||||||
|
`payroll/SKILL.md`
|
||||||
|
|
||||||
|
Multiple skills may apply. Read all applicable skills.
|
||||||
|
|
||||||
|
For example, implementing the Lohnsteuer core (AP3) normally requires:
|
||||||
|
|
||||||
|
1. `odoo19-development/SKILL.md`
|
||||||
|
2. `payroll/SKILL.md`
|
||||||
|
|
||||||
|
Work on the VRV bridge module (`l10n_at_gemeinde_payroll_vrv`) happens in
|
||||||
|
the gem360 repository; there, additionally consult the gem360 skills
|
||||||
|
(`odoo19-accounting`, `vrv2015`, `accounting-review`).
|
||||||
|
|
||||||
|
## Mandatory development workflow
|
||||||
|
|
||||||
|
All non-trivial implementation tasks follow this workflow:
|
||||||
|
|
||||||
|
### 1. Understand
|
||||||
|
|
||||||
|
Before changing anything:
|
||||||
|
|
||||||
|
- read `AGENTS.md`;
|
||||||
|
- read all applicable skills;
|
||||||
|
- inspect the existing implementation;
|
||||||
|
- search the Odoo 19 source for existing functionality;
|
||||||
|
- inspect relevant tests;
|
||||||
|
- inspect relevant legal source material under `personalverrechnung/`
|
||||||
|
and `.firecrawl/` (local, not versioned);
|
||||||
|
- identify dependencies and integration points.
|
||||||
|
|
||||||
|
Do not modify files during this phase.
|
||||||
|
|
||||||
|
### 2. Plan
|
||||||
|
|
||||||
|
Produce a concise implementation plan containing:
|
||||||
|
|
||||||
|
- understanding of the requirement;
|
||||||
|
- relevant existing Odoo functionality;
|
||||||
|
- files/components likely to change;
|
||||||
|
- proposed implementation;
|
||||||
|
- data/model/report implications;
|
||||||
|
- tests to add or modify;
|
||||||
|
- relevant legal/accounting considerations;
|
||||||
|
- potential risks or unresolved questions.
|
||||||
|
|
||||||
|
### 3. Wait for approval
|
||||||
|
|
||||||
|
**STOP after presenting the plan.**
|
||||||
|
|
||||||
|
Do not create, modify, delete, or rename files until the user explicitly approves
|
||||||
|
the plan.
|
||||||
|
|
||||||
|
Questions and clarification are allowed during this phase.
|
||||||
|
|
||||||
|
### 4. Implement
|
||||||
|
|
||||||
|
After approval:
|
||||||
|
|
||||||
|
- implement the approved plan;
|
||||||
|
- prefer existing Odoo functionality over custom implementations;
|
||||||
|
- keep the change as small and upgrade-friendly as practical;
|
||||||
|
- do not introduce unrelated refactoring;
|
||||||
|
- follow Odoo 19 coding and Git guidelines.
|
||||||
|
|
||||||
|
If implementation reveals that the approved plan is materially wrong or
|
||||||
|
incomplete, stop and explain the discrepancy rather than silently expanding
|
||||||
|
scope.
|
||||||
|
|
||||||
|
### 5. Validate
|
||||||
|
|
||||||
|
Run appropriate tests and checks.
|
||||||
|
|
||||||
|
At minimum:
|
||||||
|
|
||||||
|
- relevant Odoo tests;
|
||||||
|
- module installation/update checks where appropriate;
|
||||||
|
- Python/XML validation;
|
||||||
|
- linting/static checks available in the repository.
|
||||||
|
|
||||||
|
Validate the legal semantics (Lohnsteuer/SV values against the verified
|
||||||
|
sources in `personalverrechnung/`) as well as technical correctness.
|
||||||
|
|
||||||
|
### 6. Review
|
||||||
|
|
||||||
|
Before considering the task complete, review the resulting changes for:
|
||||||
|
|
||||||
|
- correctness;
|
||||||
|
- Odoo framework integration;
|
||||||
|
- reuse of existing Odoo functionality;
|
||||||
|
- maintainability;
|
||||||
|
- security/access rights;
|
||||||
|
- multi-company behavior;
|
||||||
|
- unnecessary custom code;
|
||||||
|
- regression risk.
|
||||||
|
|
||||||
|
## Verify before assuming
|
||||||
|
|
||||||
|
Never invent or assume the existence of an API.
|
||||||
|
|
||||||
|
Before using a:
|
||||||
|
|
||||||
|
- Python package;
|
||||||
|
- Odoo module;
|
||||||
|
- Odoo model;
|
||||||
|
- field;
|
||||||
|
- method;
|
||||||
|
- XML ID;
|
||||||
|
- configuration key;
|
||||||
|
- external API;
|
||||||
|
|
||||||
|
verify that it exists in the current Odoo 19 Enterprise source,
|
||||||
|
installed environment, or declared project dependencies.
|
||||||
|
|
||||||
|
Do not infer existence from model naming conventions, previous Odoo versions,
|
||||||
|
documentation alone, training knowledge, or similarly named components.
|
||||||
|
|
||||||
|
If existence cannot be verified, stop and report the uncertainty.
|
||||||
|
|
||||||
|
In particular, never add a dependency merely because it would be a plausible
|
||||||
|
package name.
|
||||||
|
|
||||||
|
## Prefer framework functionality
|
||||||
|
|
||||||
|
Before implementing custom functionality, search the Odoo 19 Enterprise and
|
||||||
|
community source available to the project for an existing mechanism.
|
||||||
|
|
||||||
|
Prefer, in order:
|
||||||
|
|
||||||
|
1. existing Odoo functionality that already satisfies the requirement;
|
||||||
|
2. extending an existing Odoo mechanism;
|
||||||
|
3. composing existing Odoo mechanisms;
|
||||||
|
4. a small project-specific implementation only when the above are insufficient.
|
||||||
|
|
||||||
|
Do not duplicate functionality merely because implementing it locally appears
|
||||||
|
simpler.
|
||||||
|
|
||||||
|
When choosing a custom implementation over an existing Odoo mechanism, explain
|
||||||
|
the reason in the plan.
|
||||||
|
|
||||||
|
## Git
|
||||||
|
|
||||||
|
Follow the Odoo 19 Git guidelines.
|
||||||
|
|
||||||
|
When working with Git:
|
||||||
|
|
||||||
|
- Keep commits focused and logically coherent.
|
||||||
|
- Prefer one module per commit where practical.
|
||||||
|
- Do not mix unrelated changes.
|
||||||
|
- Review the staged diff before committing.
|
||||||
|
- Never commit secrets, credentials, client data, local configuration, or
|
||||||
|
unrelated generated files.
|
||||||
|
- Do not create a commit unless the user explicitly asks for one or the task
|
||||||
|
explicitly requires it.
|
||||||
|
- When committing, use the Odoo commit-message conventions configured in
|
||||||
|
Zed's `agent.commit_message_instructions`.
|
||||||
@@ -0,0 +1,42 @@
|
|||||||
|
# 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_hr_payroll_private` | **General-AT** (KV-basierte Privatwirtschaft) — Gerüst, eigener Plan folgt |
|
||||||
|
|
||||||
|
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 Enterprise: Geschwister-Checkout `../odoo` (gleicher Stand wie
|
||||||
|
die gem360-Entwicklung; Pin bei Odoo-Upgrades in beiden Repos validieren).
|
||||||
|
- 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
|
||||||
|
python3 ../odoo/odoo-bin -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-source>/addons,<odoo-enterprise>/addons,addons
|
||||||
|
```
|
||||||
|
|
||||||
|
Dazu je Änderung: `py_compile` über alle Python-Dateien und
|
||||||
|
XML-Well-formedness-Check (Konvention wie im gem360/vrv2015-Workflow).
|
||||||
@@ -0,0 +1,9 @@
|
|||||||
|
# l10n_at_hr_payroll_private (Gerüst)
|
||||||
|
|
||||||
|
General-AT-Payroll (KV-basierte Privatwirtschaft: KV-Gehaltskataloge,
|
||||||
|
AZG/UrlG-Arbeitszeit, 13./14. Bezüge, Abfertigung Neu) — **folgt als
|
||||||
|
eigener, zur Freigabe vorzulegender Plan.**
|
||||||
|
|
||||||
|
Rahmen: `personalverrechnung/PLAN-payroll-bgld.md` (Abschnitt 4,
|
||||||
|
Schätzrahmen) und `personalverrechnung/PLAN-repo-split.md` (Ziel-Struktur,
|
||||||
|
~125–175 PT Zusatzaufwand). Kein Manifest/Code bis zur Freigabe.
|
||||||
@@ -0,0 +1,17 @@
|
|||||||
|
# CHANGELOG — odoo-at-payroll
|
||||||
|
|
||||||
|
## 2026-09-09 — Repo-Split aus gem360 (Migration)
|
||||||
|
|
||||||
|
- History-Import der Payroll-Commits aus `gem360-git` (Branch
|
||||||
|
`dev-payroll`, pfad-gefiltert via `git filter-repo`; siehe
|
||||||
|
`personalverrechnung/PLAN-repo-split.md`). Branch heißt hier `main`.
|
||||||
|
- `l10n_at_hr_payroll` (19.0.1.0.0) ausgegründet: SV-Werte 2026 als
|
||||||
|
`hr.rule.parameter`-Seed, TASY-Mapping + Import-Wizard; Modelle
|
||||||
|
umbenannt `gemeinde.payroll.tasy.*` → `l10n.at.payroll.tasy.*`.
|
||||||
|
- `l10n_at_gemeinde_payroll` → 19.0.1.4.0: hängt nun an
|
||||||
|
`l10n_at_hr_payroll` statt `l10n_at_vrv2015` (VRV-Verbleib: Brücke
|
||||||
|
`l10n_at_gemeinde_payroll_vrv` im gem360-Repo, AP7); Beschreibung auf
|
||||||
|
AP1+AP2-Stand korrigiert.
|
||||||
|
- Bootstrap: `AGENTS.md`, Skills (payroll, odoo19-development,
|
||||||
|
agent-memory), README, CHANGELOG; `l10n_at_hr_payroll_private` als
|
||||||
|
Gerüst (README only).
|
||||||
Reference in New Issue
Block a user