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.
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.