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