Payments #5

New issue

Closed

opened 2026-10-06 19:49:23 +02:00 by yhrel · 2 comments

yhrel commented

2026-10-06 19:49:23 +02:00

Collaborator

This is a simple version of the end goal of connecting to bank data in order to automatically detect who paid their membership and when.

For now, the scope is:

Be able to save and view if a comrade paid their membership
A payment can be entered for any year, past present or future
A payment is linked to a type of membership, to allow for tracking double affiliation, and to stay generic
Filter comrades by those that paid / did not pay for the current period

Implementation details:

Add a model for payment type (section id, name, amount [numeric, assume CHF], start date field [custom person date field to start counting periods from] [nullable]) cascade when purging
Add a model for payment (comrade id, payment type id, paid at, for period [unique per comrade id, payment type] [saves the start of the period as a date (calendar year)], amount [numeric, assume CHF, can differ from payment type amount], comments [nullable]). hard deleted, cascade
Add a UI for CRUD payment types
Add a UI for CUD payments (under a comrade. dropdown for existing payment types, amount defaults to payment type amount, period defaults to next period after last paid for that comrade. if no last paid, uses first period from custom start date field or current period)
Add a UI for reading a comrade's payments for each payment type, showing all periods starting from the comrade's custom start date field (no entry for the period = not paid), or the current period if no custom field is given, until the greatest of the current period and the last paid period. Do not show a payment type if it has no payments
Add a filter to the existing search system

Open questions:

Custom role for entering payments ? Probably not, if you can edit a user, you can edit their payments.
Could add a recurrence [monthly, yearly] field, but that's overkill since we only have yearly payments for now.

This is a simple version of the end goal of connecting to bank data in order to automatically detect who paid their membership and when. For now, the scope is: - Be able to save and view if a comrade paid their membership - A payment can be entered for any year, past present or future - A payment is linked to a type of membership, to allow for tracking double affiliation, and to stay generic - Filter comrades by those that paid / did not pay for the current period Implementation details: - Add a model for payment type (section id, name, amount [numeric, assume CHF], start date field [custom person date field to start counting periods from] [nullable]) cascade when purging - Add a model for payment (comrade id, payment type id, paid at, for period [unique per comrade id, payment type] [saves the start of the period as a date (calendar year)], amount [numeric, assume CHF, can differ from payment type amount], comments [nullable]). hard deleted, cascade - Add a UI for CRUD payment types - Add a UI for CUD payments (under a comrade. dropdown for existing payment types, amount defaults to payment type amount, period defaults to next period after last paid for that comrade. if no last paid, uses first period from custom start date field or current period) - Add a UI for reading a comrade's payments for each payment type, showing all periods starting from the comrade's custom start date field (no entry for the period = not paid), or the current period if no custom field is given, until the greatest of the current period and the last paid period. Do not show a payment type if it has no payments - Add a filter to the existing search system Open questions: 1. Custom role for entering payments ? Probably not, if you can edit a user, you can edit their payments. 1. Could add a recurrence [monthly, yearly] field, but that's overkill since we only have yearly payments for now.

yhrel added this to the Intégration JPOP project

2026-10-06 19:49:49 +02:00

yhrel closed this issue

2026-10-22 15:26:08 +02:00

yhrel changed title from ~~Test~~ to Payment fields

2026-10-22 15:27:41 +02:00

yhrel reopened this issue

2026-10-22 15:27:43 +02:00

yhrel changed title from ~~Payment fields~~ to Payments

2026-10-22 16:12:52 +02:00

yhrel self-assigned this

2026-10-22 16:36:47 +02:00

wbouzour commented

2026-10-25 10:19:56 +01:00

Owner

Could be done in the future, but not needed as of now.
I think it's best if we manually enter each payment. And when we do the Postfinance integration, it won't matter anymore.

1. Could be done in the future, but not needed as of now. 2. I think it's best if we manually enter each payment. And when we do the Postfinance integration, it won't matter anymore.

yhrel referenced this issue from a pull request that will close it,

2026-10-27 13:22:53 +01:00

Implement payments #8

yhrel commented

2026-10-27 13:27:20 +01:00

Author

Collaborator

Implemented in #8

wbouzour closed this issue

2026-10-28 11:23:08 +01:00