[ADD] #75 wizard for allocation vacations

[hbrunn]

das in Odoo's Standard-Allocation zu integrieren ist nicht ganz trivial, daher heute als eigenen Wizard so dass Du schonmal die Berechnung anschauen kannst, und mir sagen wie weiter ;-)

[codecov]

Codecov Report

Attention: Patch coverage is 94.28571% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 86.57%. Comparing base (868dfc8) to head (6e08740).

Files	Patch %	Lines
...do_attendance/wizards/verdigado_holidays_wizard.py	93.93%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             15.0     #107      +/-   ##
==========================================
+ Coverage   85.08%   86.57%   +1.49%     
==========================================
  Files          13       15       +2     
  Lines         181      216      +35     
  Branches       26       37      +11     
==========================================
+ Hits          154      187      +33     
- Misses         25       26       +1     
- Partials        2        3       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[albig]

Ich jetzt erst dazu gekommen, mir das anzuschauen. Ich hab den Wizard auch gefunden. Technisch sicher logisch, das beim Mitarbeiter-Datensatz anzuordnen. Damit kann ich aber immer nur für den jeweiligen Mitarbeiter den Urlaub anlegen, oder?

Ich hätte den Wizard im "Time Off" Modul gesucht, wo die bisherige Urlaubs-Allocation stattfindet und auch z.B. die Feiertags-Konfiguration. Und/oder bei der Übersicht der Mitarbeiter, um dann für mehrere Mitarbeiter den Urlaubs-Anspruch zu erstellen. Also hier z.B.:

Praktisch hab ich's leider nicht geschafft, einen Anspruch anzulegen:

[hbrunn]

die Idee ist, dass Du in der Liste alle Employees selektierst für die Du Urlaub anlegen willst.

Wenn das in ein Menü soll, muss ich das umdrehen, so dass Du im Wizard dann Employees wählst, geht auch. Soll ich das entsprechend andern? Und wo genau soll der Menüeintrag hin?

Kann ich noch einen Screenshot der Konfiguration des Urlaubstyps sehen? Da scheine ich andere approval-Regeln anzunehmen als dieser Urlaub hat.

[albig]

Hier mal der Screenshot des Urlaubs-Typs, den ich verwenden wollte:

Ich verstehe, man könnte mehrer Mitarbeiter aus der Liste auswählen und dann für diese den Urlaub anlegen. Aber zur Kontrolle muss man dann ja ins Time-Off-Modul. Drum wäre es mir schon logischer, man legt den Urlaubs-Anspruch dann gleich im Time-Off-Modul an. Bisher macht man das ja hier:

[hbrunn]

zur Kontrolle öffnet der Wizard bisher nach getaner Arbeit eine Liste der erzeugten Allocations, ich habe soeben einen Fix gepushed mit dem Du das testen kannst.

[albig]

Cool. Wenn man weiß, wie's geht.... Jetzt legt er sie an. Nur die Summen stimmen nicht. Muss erst mal etwas experimentierne, bevor ich das erklären kann. (Manche Mitarbeiter haben >100% Urlaubstage bekommen)

[albig]

Also das stimmt nicht. Der weist bei den Beispielen 1,2,3 jeweils die Wochenarbeitszeit (32h, 40h, 24h) dem Mitarbeitenden als Jahresurlaubstage (32d, 40d, 24d) zu.

Beim Beispiel 4 haut das nicht hin. Hier ist die Wochenarbeitszeit 25h. Es werden 24.8 Tage zugewiesen.

[hbrunn]

@albig jetzt mit angepasster Berechnung und dual use Menü/Kontextmenü

[albig]

Das sieht schon mal gut aus.

Wenn ein Arbeitsplan am 30.06.2025 endet, wird der Juni nicht vollständig berücksichtigt. Kannst Du da noch mal drauf schauen?

Beispiel:

1. Arbeitsplan: bis 30.06.2025 --> 14.7 Tage --> müsste 15 Tage sein
2. Arbeitsplan: ab 01.07.2025 --> 15 Tage

[hbrunn]

zur Zeit mache ich (enddatum_kalender - startdatum_kalendar) / (enddatum_interval - startdatum_interval), dh. das ist auf Tage genau.

Soll ich das anpassen dass wenn ein Kalender in Monatsgrenzen definiert ist, es auf anteilige Monate umschaltet?

Oder immer (endmonat - beginmonat) / (monate des Intervalls, meistens 12) fur den Anteil?

[albig]

Mmh. Dann ist wohl das erste Halbjahr um nen Tag kürzer, kann das sein? Wenn ich die Vertrags-"Trennung" auf 1.6. setze, dann würde es passen.

Wir brauchen es tatsächlich monatsweise und es gibt auch nur ganze Tage. D.h. hier müsste im Sinne der Arbeitnehmer aufgerundet werden.

Ein weiterer Use-Case ist: Vertragswechsel Mitte des Monats. Dann wird's beliebig kompliziert :-(

Beispiel:

• Arbeitsplan A bis 14.06. 3 Tage die Woche --> 18 Tage pro Jahr == 1,5 Tage pro Monat --> Januar bis Mai 7,5 Tage, Juni 0,75. Zusammen 8,25 Tage --> also 9 Tage.
• Arbeitsplan B ab 14.06. 5 Tage die Woche --> 30 Tage pro Jahr --> 15 Tage.
  --> 24 Tage.

Einfacher:

• Arbeitsplan A bis 14.06. 5 Tage die Woche --> 30 Tage pro Jahr == 2,5 Tage pro Monat --> Januar bis Mai 12,5 Tage, Juni 1,25 Tage, --> also 14 Tage
• Arbeitsplan B ab 15.06. 5 Tage die Woche --> 15 Tage + 1,25 --> 17 Tage.
• --> 31 Tage - was ja auch nicht stimmt.

Am genauesten scheint es mir, wir bleiben bei der aktuellen Berechnung und folgen Deinem Vorschlag:

Soll ich das anpassen dass wenn ein Kalender in Monatsgrenzen definiert ist, es auf anteilige Monate umschaltet?

[hbrunn]

ja, der Februar mit 28/29 Tagen stört die Balance.

Jetzt schalte ich in die Monatsberechnung wenn ein Kalender am 1. anfängt und/oder am Monatsende aufhört, und das fur das Intervall der Allocation auch gilt (was fur das ganze Jahr ja immer der Fall ist).

Runden: Die Zwischenergebnisse runde ich mit zwei Dezimalen, und am Ende runde ich auf auf ganze Zahlen

[albig]

Jetzt kommen ganze Zahlen raus. Super.

Aber hier klemmt es leider noch:

Use-Case 1

• Vertrag bis 30.06. 5 Tage-Woche (15 Tage Urlaubsanspruch)
• Vertrag ab 01.07. 5 Tage-Woche (15 Tage)
  liefert 31 statt 30 Tage

Use-Case 2

• Vertrag bis 28.02. 4 Tage-Woche (4 Tage)
• Vertrag ab 01.03. 5 Tage-Woche (25 Tage)
  liefert 28 statt 29 Tage

Use-Case 3

• Vertrag bis 15.02. 4 Tage-Woche (3 Tage)(*)
• Vertrag ab 16.02. 5 Tage-Woche (~26,25 Tage)(*)
  liefert 26 Tage statt 29 Tage

Bei (*) bin ich mir auch unsicher, wie es korrekt berechnet wird. Aber 26 Tage sind definitv falsch.

[hbrunn]

hmm, ich habe gerade Tests geschrieben die die obigen Szenarios abdecken, und bekomme genau Deine erwarteten Werte: https://github.com/verdigado/odoo-customize/pull/107/files#diff-ed0052146289db2d52711a7dd4e25f128d1a3ab365fa6a35bc60aab469d7e60bR98-R206

Siehst Du einen Unterschied mit Deinen Testdaten?

[albig]

Ebenso "mmh" :-( Ich kann das nicht mehr nachvollziehen. Hatte einiges probiert und während des Schreibens bin ich zu den Ergebnissen gekommen. Der Code-Stand hätte aktuell sein sollen. Dann muss ich da einen Fehler gemacht haben.

Eins hab ich aber noch: "Date Start" und "Date End" hat mich zunächst in die Irre geführt. Das ist ja die "Validity Period". Die ist aber nicht zwingend mit dem Kalenderjahr identisch. Üblicherweise sind die Ansprüche bis Tag X des Folgejahres gültig. Oft 31.03. Oder man lässt es einfach offen.

Nutzt Du das "Date-End" für die Berechnung aktuell überhaupt oder setzt Du damit nicht einfach nur die "Validation End"?

Logischer fände ich folgendes:

1. Select-Box / Feld für das Jahr: YYYY
2. Validity Period Start: volles Datum, vorbelegt mit 01.01.YYYY (--> könnte manuell z.B. auch der 1.12. des Vorjahrs sein)
3. Validity Period End: optionales Datumsfeld, nicht vorbelegt

Könntest Du das noch bitte umsetzen? Dann sieht es IMHO sehr gut aus.

Gültigkeit ganzes Jahr

• Standard 40 hours/week
• Vacation days 100%: 30
• Date-Start 01/01/2025
• Date-End 12/31/2025
  --> Ergebnis 30 Tage --> korrekt

[hbrunn]

jetzt mit Trennung Bezugsintervall (=year) und Gültigkeit (=date_{start,end}). Schreibst Du hier noch wenn das okay ist? Dann squashe ich noch die commits

[albig]

Sieht gut aus, aber ich laufe in folgenden Fehler rein:

  File "/usr/lib/python3/dist-packages/odoo/api.py", line 456, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "/mnt/extra-addons/verdigado_attendance/wizards/verdigado_holidays_wizard.py", line 46, in button_assign_vacation
    interval_start = date(self.year, 1, 1)
Exception

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/odoo/http.py", line 654, in _handle_exception
    return super(JsonRequest, self)._handle_exception(exception)
  File "/usr/lib/python3/dist-packages/odoo/http.py", line 301, in _handle_exception
    raise exception.with_traceback(None) from new_cause
TypeError: an integer is required (got type str)

Nach dem gescheiterten Versuch den Anspruch anzulegen ist das Formular beim Feld "Year" dann leer, obwohl es initial befüllt war.

Zwei Fragen / Bitten:

• ich würde year + 3 machen. Also dass jetzt schon 2026 auswählbar ist.
• ist es möglich im Feld "Validity end" den Anfangswert im Datepicker auf den Wert von "Validity start" zu setzen?

[hbrunn]

jetzt sollte das tun. Die Sache mit dem default fur end_validity verstehe ich nicht wirklich, habe es aber einfach mal gemacht

[albig]

Ja, das funktioniert jetzt. Mit dem Default für end_validity meine ich:

• start_validity wird gesetzt auf 01.01.2025
• klicke ich auf end_validity startet der Datepicker (vorher) beim aktuellen Monat (also März 2024). Ich muss also mühsam mich zum z.B. 31.03.2026 durchklicken.
• jetzt startet er beim 01.01.2025 also ein bisschen besser

Ich vermute, dass JavaScript ist und wenn Odoo dafür nix vorgesehen hat, dann ist es halt so umständlich. Ist ja bei den Zeilen für Anwesenheiten genauso gelöst.

[hbrunn]

danke, verstehe. Soeben noch die commits gesquashed