On 08/12/2016 08:02 PM, Aaron Wolf wrote:
> On 08/12/2016 06:58 PM, Stephen Michel wrote:
>> <snip>
>> I think that this scenario is really hard to parse. It could also result in 
>> a display where you have a carryover from may and a carryover from June 
>> displayed in July, and that gets really busy really quickly (especially if 
>> one or more are also carried over to august).
>> I suggest that we aggregate all carryover charges. The small loss in detail 
>> is totally worth the simplicity, imo.
> Absolutely! Describing the carry-over from several months with separate
> list of carry-overs would be crazy. But the aggregated sum can be
> described as month-month e.g. "March-July carry-over". Effectively, most
> carry-overs will only happen at the early stage of projects and patrons,
> when they first start on the system. A new project with some new patrons
> may have a period of carry-overs, and then no more of that going
> forward. So, it's just this contiguous set of months that will have
> carry-overs in almost all cases.
> To cover all possible scenarios, we could just say "carry-over from
> earlier months with charges too low to be worth charging" effectively.
> In any case, it should be one sum number.

That's already what I intended: At most one carry over from the previous
month and one carry over to the next month.  I don't even think we
should try to describe what multiple months it may originally come from
(e.g. no attempt at "March-July carry-over" etc) because that will just
get too complicated, particularly in the "widdle-away" scenario when
part of a carry over is paid off in one month but part is carried over
to the next month.

It would probably be clearer to go back to referring to "next month" and
"previous month" as I'd done previously, rather than naming the specific
last and previous months as I tried in this latest version.

Attachment: signature.asc
Description: OpenPGP digital signature

Design mailing list

Reply via email to