Remmer/stiftung-management-system
1
0
Fork 0
Code Issues Pull Requests 1 Actions 8 Packages Projects Releases Wiki Activity

Decouple Q1/Q3 support payments from study proof requirement (STI-107) #1

Merged
Remmer merged 2 commits from fix/sti-107-q3-zahlungspipeline into main 2026-06-14 20:33:05 +00:00
Conversation 0 Commits 2 Files Changed 3 +260 -18
Remmer commented 2026-06-14 20:15:41 +00:00
Owner
Copy Link

Worum geht es?

Q3-Unterstützungszahlungen wurden ab 15.06. nie automatisch erzeugt, weil VierteljahresNachweis.is_complete() einen Studiennachweis verlangt — dessen Frist liegt aber für Q3 erst am 15.09. (analog Q1: Zahlung 15.12. vs. Studiennachweis 15.03.). Damit blieb create_quarterly_support_payment() immer auf None, und auch das manuelle Bearbeiten des Q3-Nachweises (Status: offen) erzeugte keine fällige Zahlung. Siehe Diagnose in STI-107.

Was ändert dieser PR?

  • Neue Methode VierteljahresNachweis.is_complete_for_payment(): prüft für Q1/Q3 nur Einkommens- und Vermögenssituation (Studiennachweis fällt nach der Zahlung an); für Q2/Q4 unverändert wie is_complete() (Studiennachweis und Zahlung fallen gleichzeitig).
  • create_quarterly_support_payment() und alle Status-Übergänge in quarterly_confirmation_update, quarterly_confirmation_edit, quarterly_confirmation_reset sowie VierteljahresNachweis.save() nutzen die neue Methode für zahlungsrelevante Gates.
  • is_complete() bleibt unverändert (UI-Vollständigkeitsbadge).

Was muss noch entschieden werden (nicht Teil dieses PRs)

  • Daten-Backfill für Q3/2026 (Lorenz und ggf. weitere Destinatäre): braucht User-Freigabe zum Scope. Offen in STI-107 (Interaction 686cab1f, Hotfix-Scope: alle aktiven / nur Lorenz / Kandidatenliste).
  • Nach Merge: bestehende Q3/2026-Nachweise mit offen-Status werden beim nächsten Edit/Save automatisch zu eingereicht, sofern Einkommen+Vermögen bestätigt sind. Auszahlung entsteht dann beim nächsten Speichern oder bei Staff-Approve.

Verifikation lokal nach Merge

  • python manage.py shell → Q3-Nachweis mit einkommenssituation_bestaetigt=True (plus Text/Datei) + vermogenssituation_bestaetigt=True (plus Text/Datei) → nachweis.is_complete_for_payment() == True
  • create_quarterly_support_payment(nachweis) liefert eine DestinataerUnterstuetzung mit faellig_am=15.06.<jahr> zurück.
  • Q2/Q4-Verhalten unverändert (Studiennachweis weiterhin erforderlich).

Refs STI-107

## Worum geht es? Q3-Unterstützungszahlungen wurden ab 15.06. nie automatisch erzeugt, weil `VierteljahresNachweis.is_complete()` einen Studiennachweis verlangt — dessen Frist liegt aber für Q3 erst am 15.09. (analog Q1: Zahlung 15.12. vs. Studiennachweis 15.03.). Damit blieb `create_quarterly_support_payment()` immer auf `None`, und auch das manuelle Bearbeiten des Q3-Nachweises (`Status: offen`) erzeugte keine fällige Zahlung. Siehe Diagnose in [STI-107](/STI/issues/STI-107). ## Was ändert dieser PR? - **Neue Methode `VierteljahresNachweis.is_complete_for_payment()`**: prüft für Q1/Q3 nur Einkommens- und Vermögenssituation (Studiennachweis fällt nach der Zahlung an); für Q2/Q4 unverändert wie `is_complete()` (Studiennachweis und Zahlung fallen gleichzeitig). - **`create_quarterly_support_payment()`** und alle Status-Übergänge in `quarterly_confirmation_update`, `quarterly_confirmation_edit`, `quarterly_confirmation_reset` sowie `VierteljahresNachweis.save()` nutzen die neue Methode für zahlungsrelevante Gates. - `is_complete()` bleibt unverändert (UI-Vollständigkeitsbadge). ## Was muss noch entschieden werden (nicht Teil dieses PRs) - **Daten-Backfill für Q3/2026** (Lorenz und ggf. weitere Destinatäre): braucht User-Freigabe zum Scope. Offen in [STI-107](/STI/issues/STI-107) (Interaction `686cab1f`, Hotfix-Scope: alle aktiven / nur Lorenz / Kandidatenliste). - Nach Merge: bestehende Q3/2026-Nachweise mit `offen`-Status werden beim nächsten Edit/Save automatisch zu `eingereicht`, sofern Einkommen+Vermögen bestätigt sind. Auszahlung entsteht dann beim nächsten Speichern oder bei Staff-Approve. ## Verifikation lokal nach Merge - `python manage.py shell` → Q3-Nachweis mit `einkommenssituation_bestaetigt=True` (plus Text/Datei) + `vermogenssituation_bestaetigt=True` (plus Text/Datei) → `nachweis.is_complete_for_payment() == True` - `create_quarterly_support_payment(nachweis)` liefert eine `DestinataerUnterstuetzung` mit `faellig_am=15.06.<jahr>` zurück. - Q2/Q4-Verhalten unverändert (Studiennachweis weiterhin erforderlich). Refs STI-107
Remmer added 1 commit 2026-06-14 20:15:41 +00:00
Decouple Q1/Q3 support payments from study proof requirement (STI-107)
Some checks are pending
CI/CD Pipeline / test (pull_request) Waiting to run
Details
CI/CD Pipeline / deploy (pull_request) Blocked by required conditions
Details
Code Quality / quality (pull_request) Waiting to run
Details
6d8b35a7da 
Q3 support payments fall due on 15 June, but the matching study proof
deadline is 15 September of the same year. The previous gate
`VierteljahresNachweis.is_complete()` required the study proof to be
present, so `create_quarterly_support_payment()` returned None for every
Q3 entry — Q3/2026 payments never appeared in the pipeline even after
the staff manually updated the quarterly confirmation. The same
mismatch exists for Q1 (payment 15 December, study proof 15 March).

Introduce `is_complete_for_payment()` on VierteljahresNachweis that
skips the study proof check for Q1 and Q3 (where the study proof
falls due after the matching payment) while keeping the strict
`is_complete()` requirement for Q2 and Q4 (where both deadlines
coincide on 15 March / 15 September).

Use the new check in the payment-creation gate and in the status
transitions in `quarterly_confirmation_update`, `quarterly_confirmation_edit`,
and `quarterly_confirmation_reset`, so Q1/Q3 confirmations can reach
'eingereicht' on income+assets alone and the support payment is
created on the correct due date.

Refs STI-107

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Remmer added 1 commit 2026-06-14 20:25:06 +00:00
Add backfill_quarterly_payments command for one-off catch-up (STI-107)
Some checks are pending
CI/CD Pipeline / test (pull_request) Waiting to run
Details
CI/CD Pipeline / deploy (pull_request) Blocked by required conditions
Details
Code Quality / quality (pull_request) Waiting to run
Details
e76f765d0c 
Companion to the Q1/Q3 payment decoupling. Iterates active destinatare
with vierteljaehrlicher_betrag > 0 and IBAN set, finds or creates the
matching VierteljahresNachweis, and produces a DestinataerUnterstuetzung
via create_quarterly_support_payment() when the new is_complete_for_payment()
gate passes.

For Q3/2026 where the staff did not record income/assets reviews on every
destinatare before the 15.06. payment date, --force bypasses the gate and
inserts a 'geplant' payment directly, tagged "Backfill STI-107", so the
staff can still process it through the normal pipeline.

Supports --dry-run to preview without writing. Skips destinatare that
already have a payment for the same quarter and lists every skip reason
at the end.

Refs STI-107

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Remmer merged commit d9794458dd into main 2026-06-14 20:33:05 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Remmer
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Remmer/stiftung-management-system#1
No description provided.
Delete Branch "fix/sti-107-q3-zahlungspipeline"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?