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

feat: introduce a balance model #425

Open
braaar opened this issue Feb 6, 2023 · 0 comments
Open

feat: introduce a balance model #425

braaar opened this issue Feb 6, 2023 · 0 comments

Comments

@braaar
Copy link
Collaborator

braaar commented Feb 6, 2023

Hacklab JKL is interested in adding a new (optional) payment model to mulysa.

We don't use mulysa (yet) and currently operate with a simple double entry bookkeeping model where a member has a certain balance with the hacklab. Some members owe money to the hacklab if they haven't paid for their memberships or services, and some members have a positive balance if they have paid extra up front. The member uses the same payment reference in bank transfers no matter what they are paying for, since they are just paying into their total balance. This makes it so that we don't have to nag people about new references and it's just a bit less work.

For every month that a member has an active membership, a certain amount of "debt" is added to the balance. Other services (including one time services) can also add debt to the balance. When money comes in with a certain reference, money is added to the balance.

A member's balance sheet may look something like this:

Event Date Sum (€)
Membership fee Dec 2022 2022-12-01 –10
Bank transfer 2022-12-03 10
Membership fee Jan 2023 2023-01-01 –10
Bank transfer 2023-01-05 15
Arduino class Jan 23 2023-01-15 –5

Balance: 0

I think such a model can be implemented in mulysa alongside the existing financial model. We can allow admins to configure which payment/accounting model they wish to use.

In Hacklab Jyväskylä, we believe that this model simplifies a lot of things compared to mulysa's current mode. I can see that there are cases such as #125 and #345 where this model would be easier to work with. But I also think co-existence is very doable.

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

Successfully merging a pull request may close this issue.

1 participant