Skip to content

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

@braaar

Description

@braaar

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions