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
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.
The text was updated successfully, but these errors were encountered:
What happens if a member stops paying? Well, their balance would go in the red when their balance is charged for services. There should obviously be a limit to this, so that you cannot just keep using services and "put it on the tab".
For example, you could have a threshold set up so that once a member is 20€ behind on their payments, all privileges are revoked until they pay up.
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:
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.
The text was updated successfully, but these errors were encountered: