What I’m doing at the moment is changing how the membership renewals work. Previously, memberships with renewal type set to “Automatic” had new membership records created automatically when they expired, but these new memberships weren’t linked to orders or payments, and no emails or delivery documents where generated. I’m changing this so that if the information exists, an automatically renewed membership actually goes through the order process and sells a new membership to the customer. This then means that there are proper records for accounts to reconcile against membership income.
Plan A is to have the new membership use the same delivery method and payment type as the original, which will be find if the original order was marked as pay by Standing Order / deliver by post. But it means that if the original membership was bought for cash over the counter, and then manually changed to autorenew, the renewal order will also be logged to cash. The alternative, I suppose, is to leave Direct Debit and Standing Order alone but change all other payment types to a default.
Ok, so now I’m selling the new membership as a new order, and I’m using the same payment type as long as the payment type is in DirectDebit or StandingOrder, and if it’s anything else I’m changing it to DirectDebit (default to be configurable)
So I need to create a new payment record. I could set the payment amount
To the current cost of the membership
To the amount paid last time.
The obvious sensible answer should be (1). But what if the original standing order was deliberately set for more than the membership price in order to give a donation and / or what if the membership price is increased?
Perhaps it should be
“Current cost of the membership PLUS any donations that were in the original order.”
or
“Whatever is larger: the amount paid last time or the current cost of the membership”
The trouble with all these options as that as it’s running unattended - so no user interaction - and the settings are based on a previous order - which isn’t editable - I can’t think of a good way of handling the case where someone overpaid in the past as a donation but now wants to stop. I guess we could just set the membership to renew manually and sell them a new one… Yeah, that’ll do.
I wonder whether the payment type and delivery method should be attributes of the membership, in the same way renew type=manual or automatic is. When the membership renewal is set to be automatic the operator can choose the values, perhaps defaulted to the values from the order.
On how much to charge: One difference between direct debit and standing order is that the amount can be varied for DD but fixed for SO. Also the organisation is control of a DD amount and frequency but the individual controls a SO. https://gocardless.com/guides/intro-to-direct-debit/standing-order/.
So if the membership price has increased and they paid by Standing order then I think the renewal type should be set to manual, and the customer contacted.
I don’t think we can assume someone wants to donate again just because they did the first time. Plus they may have bought tickets and a membership together initially, and donated based on that transaction (was the donations linked to the tickets or the membership?). However if they set up a SO or DD which overpays for the membership then I think we can charge that again.
So I think we need to add details of the recurring payment to the database, including type (DD or SO) frequency and amount.
I don’t think we can assume someone wants to donate again just because they did the first time. Plus they may have bought tickets and a membership together initially, and donated based on that transaction (was the donations linked to the tickets or the membership?). However if they set up a SO or DD which overpays for the membership then I think we can charge that again.
Not in general, but specifically that’s what @ymp wants.
But this does sort out another issue, which is that SADA sell a membership where the first month is paid by card and it goes to Direct Debit after that… so we need the renewal payment type as being a property of the product too, and then that goes onto the membership record.
So should the donation also live somewhere else in the database (maybe it does already?), With it’s amount; type: manual, automatic; recurrence: one-off, monthly, annual, etc.; Payment: link to payment, DD or SO record; gift aid: link to declaration. Then we can renew membership and donation independently.
What I actually did with this was add some fields to the product / userstatus table, to set the renewal payment type id, renewal product, renewal delivery method on the product.
So, you can sell a membership to card, and still have the renewal be set to direct debit, and you can have the renewal delivery method be an email notification even if the original order was over the counter.
Then, all these fields can be overridden on an individual user status if necessary.
