You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Fetch all subscriptions for the user
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)
Add together the sum for all the user's subscriptions
Calculating the subscription fees paid
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.
The text was updated successfully, but these errors were encountered:
Make bank transactions map onto subscriptions based on reference number AND date (if reference matches and the transaction occurs within the subscriptions time period)
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:
RF1234455678
)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
Calculating the subscription fees paid
The text was updated successfully, but these errors were encountered: