WIP: Payment Concept closes #210 #221
carla
simon
rafael
Labels
No labels
bug
duplicate
enhancement
help wanted
high priority
invalid
L
low priority
M
medium priority
needs refinement
question
S
UX research
wontfix
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: local-it/mitgliederverwaltung#221
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "docs/210_payment-concept"
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?
Great work!! 💯
very detailed and you already thought of all the small things :)
I just have some minor comments!
@ -0,0 +145,4 @@- `contribution_start_date` (Date, nullable)**Existing Fields Used:**- `joined_at` - For calculating contribution startWe should keep that in mind for member_fields, that joined_at and left_at should be member_fields.
@ -0,0 +234,4 @@- `mark_as_suspended` - Set status to :suspended- `mark_as_unpaid` - Set status to :unpaid (error correction)**Bulk Operations:**Maybe we give bulk operation a lower prio for now
@ -0,0 +80,4 @@- id (UUID)- name (String) - e.g., "Regular", "Reduced", "Student"- amount (Decimal) - Contribution amount in Euro- interval (Enum) - :monthly, :quarterly, :half_yearly, :yearlyI am a bit confused about the interval being connected to the type here on a global level. Isn't it more a member level decision if the member wants to pay monthly or yearly? If I allow the members to pay monthly OR quarterly would it mean I need to add two seperate contribution types?
I get that this makes calculations easier, right? And also the amount is clearly defined per interval. We just need to communicate that in a good way to the user.
I think it's a decision what is allowed on a global level. Should there be monthly payments, or only yearly.
Also the amount should be connected to the interval.
For example:
I stumpled upon this, too and I think it's a question how we handle this in the UI.
e.g. if I want to allow monthly, quarterly, half-yearly and yearly subscriptions and have 3 types of subscriptions, I have to model them by myself and find a naming scheme that supports me in the way these fee types are sorted:
Regular - monthly
Regular - quarterly
Regular - half yearly
Regular - yearly
Reduced - ...
Reduced - ...
Reduced - ...
Reduced - ...
Student - ...
...
Might be just an edge-case, but the task to create some kind of similar structure remains nevertheless.
I wonder whether we actually need to differentiate which fee type can be yearly, monthly etc. yet.
And if so, i'd argue that we should specify an
enum setfor the fee types and name it "allowed intervals" to then be able and set the actual interval member-specific.Feels cleaner to me
Actually I wonder whether an additional resource would fit the domain better:
membercontributions, which have at least acontribution type,intervalandvalidity periodcontribution periodsthat reflect the payment intervals. or maybe even call itpayment periodbecause i think the periods in which payments have to be made and checked are a different concept to those periods that a specific payment type is active for a user - and handling those via the same resource feels a bit complicated
@ -0,0 +137,4 @@### Global Settings```key: "contributions.include_joining_period"I like that you thought about this setting!
@ -0,0 +321,4 @@**Quick Marking:**- Checkbox in each row for fast marking- Button: "Mark selected as paid"Just a minor thing: [Mark as unpaid / suspended] as addition.
@ -0,0 +429,4 @@**UI Notice on Exit:**```⚠ Unpaid contributions presentIf we decide for this warning, maybe we add that also to settings that people can omit that? Or we add the warning + setting as low priority new issue, because I don't think it is that important to have that for now.
@ -0,0 +453,4 @@│ 2025 │ Yearly │ 60 € │ ☐ Open │ [ ] │└───────────────┴──────────┴────────┴──────────┴─────────┘[Mark selected as paid] (2 selected)User could also mark two as suspended here, right? So we would need "mark as paid/unpaid/suspended" depending on the current state right?
Looks very solid!
I'd argue for adding an intermediate resource between member and contribution_period as you can see from my comments
@ -0,0 +1,651 @@# Membership Contributions - Technical ArchitectureCould we call it "Membership Fee"?
Think that translation fits the context better
@ -0,0 +82,4 @@- amount (Decimal) - Contribution amount in Euro- interval (Enum) - :monthly, :quarterly, :half_yearly, :yearly- description (Text, optional)- timestampsI don't get what the timestamps are supposed for
@ -0,0 +123,4 @@- contribution_type_id (FK → contribution_types.id, NOT NULL, default from settings)- contribution_start_date (Date, nullable) - When to start generating contributions- left_at (Date, nullable) - Exit date (existing)```feels like another argument for a dedicated resource, as the contribution relevant information is spread across multiple resources where it all has a clear context and could be handled in one place
@ -0,0 +285,4 @@- "Unpaid contributions in last period"- "Unpaid contributions in current period"### Member Detail ViewI'd like if we continue the concept that all values from the member detail view can (optionally) also be shown in the membership overview.
And if thats too much information at once, i'd perspectively be able to define custom views (just with preset filters and sorting), that show up as sub-menu, like
and thus can be customized to the users likings and needs just as our default overview
@ -0,0 +353,4 @@Impact:- 45 members affected- Future unpaid periods will be generated with 65 €- Already paid periods remain with old amounthow do we handle this?
if we change the entry in database and rely on it for calculations of old periods - that won't work I guess?
ah, got it, from the amount in the contribution period
@ -0,0 +368,4 @@Selected: "Regular (60 €, Yearly)"This contribution type is automatically assigned to all new members.Can be changed individually per member.I read it as, its just pre-selected when I create a new member, but if I select something else from the drop-down I don't have to change it individually later, right?
Description is a little misleading
@ -0,0 +372,4 @@---☐ Include joining periodimportant to handle this - but we should check-in with the pilot organizations on how they
actuallyhandle it. As it affects the money members pay and organizations receive, this is rather important.e.g. is there a need to include "partly" payment periods? Maybe not daily, but if we only have a yearly regular fee, should ppl still be able to be "billed" only the remaining 2-3 months or so?
Questions for organizations:
@ -0,0 +169,4 @@**Algorithm:**1. Get `member.contribution_start_date` and `member.contribution_type`this should probably lock the whole contribution period table for the duration of the algorithm.
Payment Concept closes #210to WIP: Payment Concept closes #210View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.