On 08/03/2016 06:19 PM, Aaron Wolf wrote: > <snip> > I want to propose my solution as the *final* one for MVP: The limit is > accepted as a hard limit for any charge in any given month, because it > makes things as easy and reliable as possible for the patrons. Whenever > there needs to be a carry-over, we use the difference between a month's > charges and any outstanding carry-over from previous to reach up to the > max, and thus widdle-away the carry-over over multiple months if need be. > > A carry-over of $2 could take two or three months to widdle away if a > patron is very close to their limit otherwise. That's not a problem. And > the patron gets to just be certain no charge ever will surpass their > monthly limit. > > Even though it is *okay* to combine months it *will* result in the need > for care in the explanation and still have room for mistaken > understanding. By spreading out the carry-over over as many months as > necessary (which will usually just be one month), we remove the risk of > confusion and lose nothing valuable. > > So, I want to accept this as the solution and design the mechanism and > the transaction history around this approach. And we don't need to then > debate the issue further. > > <snip> On 08/03/2016 06:34 PM, Aaron Wolf wrote: > On 08/03/2016 05:19 PM, Aaron Wolf wrote: >> Whenever there needs to be a carry-over, we use the difference >> between a month's charges and any outstanding carry-over from >> previous to reach up to the max, and thus widdle-away the carry-over over >> multiple months if need be. >> >> Error in my wording: I meant "the difference between the max and the >> current month's charges as the amount of any carry-over that is >> available to be charged in a given month"
This approach seems like an excellent solution to me. I agree with Robert that it's better to have the monthly limit simply and unequivocally mean that your payment method will never be charged more than that in a given month, so I'm glad this discussion has resulted in a solution that achieves that while avoiding auto-suspending any pledges as a result of carry-over from previous months. Re Stephen's concerns that this would be "significantly harder/more complicated to explain and to display a history of," I think it should be possible to design the history to make it clear what's going on with this approach. When there's carry-over, we'll just need to explain the reason clearly and concisely. The two possible reasons we now have for carry-over are actually quite simple: either the amount last month was too low (below minimum charge) or it was too high (above monthly limit). _______________________________________________ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss