[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