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
Note: this issue also discusses parts of the design / implementation that concern Pycroft. I currently think that's a good idea in order to keep all the information in one place. Please speak up if you think otherwise.
The submission of repayment requests should be integrated into the membership termination workflow, as that's where most of them occur. Requests after accidental (high) transfers do happen, but a lot less frequent. We can continue to use PDF forms for such cases.
Proposed workflow:
Member sets termination date
Information / forms are shown based on (projected) remaining balance
Balance = 0: Nothing to do
Balance < 0: Display payment details to pay outstanding amount
Balance > 0: Decide what to do with remaining balance
Proposed options for Balance > 0:
Do nothing (useful when doing a term abroad, we need to check compatibility with membership fee regulations)
Donate remaining balance
Request a repayment for the remaining balance
The chosen option should be saved in Pycroft together with the other information of the scheduled cancellation. In case the scheduled membership cancellation is cancelled later, the data should be deleted. In case the scheduled membership cancellation is not cancelled until the desired date, the chosen action is executed.
For the "Do nothing" option this means nothing happens (obviously).
For the "Donate remaining balance" option an (unconfirmed?) donation transaction is created.
For the "Requests repayment" option the request will now be shown to the treasurers
The text was updated successfully, but these errors were encountered:
We should make sure that we are really entitled to take donations, as this was not always clear as far as I remember due to our legal status
For the reimbursement option, we should inform our members that the order will not become effective before the end of the membership and will be manually checked by our treasurers so a delay of up to $x weeks can be expected
When displaying the remaining balance, we should include the date of the last deposit on the member's account to not accidentally offer the wrong option
Note: this issue also discusses parts of the design / implementation that concern Pycroft. I currently think that's a good idea in order to keep all the information in one place. Please speak up if you think otherwise.
The submission of repayment requests should be integrated into the membership termination workflow, as that's where most of them occur. Requests after accidental (high) transfers do happen, but a lot less frequent. We can continue to use PDF forms for such cases.
Proposed workflow:
Proposed options for Balance > 0:
The chosen option should be saved in Pycroft together with the other information of the scheduled cancellation. In case the scheduled membership cancellation is cancelled later, the data should be deleted. In case the scheduled membership cancellation is not cancelled until the desired date, the chosen action is executed.
The text was updated successfully, but these errors were encountered: