Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion for a new membership/invoicing/payment/balance approach #11

Open
braaar opened this issue Sep 16, 2023 · 1 comment
Open

Comments

@braaar
Copy link

braaar commented Sep 16, 2023

Currently, mulysa has an invoice model that doesn't suit our use case.

I propose that we make a simplified model without invoices, like this:

  • A user has a default payment reference (e.g. RF1234455678)
  • A user can have one or more subscriptions/services assigned to them (e.g. membership, discounted membership, key access)
  • Subscriptions have a start and end date. When a user is assigned a subscription, a timestamp is stored. When a subscription is removed from a user, instead of being deleted, it is marked as ended, with a timestamp reccording this date
  • A function can calculate how much a user owes to the hacklab by looking at every subscription the user has (and has had) and adding up a sum of money, and also looking at how many

Note: A problem with this model is that if a user stops and resumes the same membership multiple times, it gets really hard to keep track of the history and calculate everything correctly.

Calculating the debt

  1. Fetch all subscriptions for the user
  2. Go through each subscription, count the number of days the subscription was active. See how many 30 day periods the subscription has been active and calculate a payment sum (e.g. if the subscription has been active for 50 days, this means the user should pay two installments of the subscription cost, if it has been active for 1 day, this means the users should pay one installment of the subscription cost)
  3. Add together the sum for all the user's subscriptions

Calculating the subscription fees paid

  1. Go through bank transactions, find transactions with the user's reference and add the sum together. Transactions with negative numbers can also be added to this sum, allowing us to perform manual debt corrections.
@braaar
Copy link
Author

braaar commented Sep 16, 2023

Alternative model:

  • Add start and end time to subscriptions
  • Allow overpaying for subscriptions
  • Make bank transactions map onto subscriptions based on reference number AND date (if reference matches and the transaction occurs within the subscriptions time period)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant