For the Evergreen 3.1 release cycle, Hekman Library at Calvin College will be dedicating development effort to completing various in-progress billing enhancements. This page exists both to express the design intentions for feedback, and also to bring together all the various billing related LaunchPad tickets into one central place.

For all of its complexities, current Evergreen does an admirable job with billing. However, it has some significant limitations regarding how it tracks and understands time, and these prevent us from making certain improvements which may otherwise seem possible. In addition, we have competing mental models in certain billing areas which might be clarified with better terminology. We believe these issues can be addressed in three steps.

• Concept: We need more, accurate data to properly understand and process the endless variations of fines.
• Relevant Bug: https://bugs.launchpad.net/evergreen/+bug/1422379
• Completion (est.): 80%

As things stand, billings are recorded with a single timestamp. In the case of overdue fines, which are by far the most common billing, this timestamp is meant to perform triple-duty: it is supposed to tell us when the fine accrued, when the billing period ended (so that we might bill again), and when the bill was actually recorded in the system. The most important of these three for communicating with patrons is knowing when the fine actually “happened”, which means knowing the moment of accrual when the item passed the due date and was subject to a fine. However, for practical reason of preventing overlapping fines the current time recorded in Evergreen is actually the second value, i.e. when the billing period ends. (This leads to the common impression that fines in Evergreen are “future dated”, which would be true if you were expecting the first value instead.)

Despite these limitations, this modest design works quite well for the normal case of an overdue fine which is valid and accrues daily. For an item due on 12/11/17, the future dated timestamp for the first fine (e.g. 12/12/17 11:59:59pm) still shows the same day as the actual accrual moment (12/12/17 12:00:00am). The same cannot be said for fines applied hourly; an item due at 2:00pm will not have first fine dated as 2:00:01pm, but actually dated at 3:00pm. It is hard to explain to the patron who returns the item late at 2:20pm why they have a bill dated for 3:00pm!

Furthermore, we run into trouble again when trying to calculate applicable bills not applied in real time. Imagine the case where a lost item is returned, and we are trying to restore overdue fines. We wish for the restored overdues to be dated after the lost fine is voided for understanding the invoice, but also to reflect the actual days being re-billed (which becomes critical if any backdating is involved). With a single date, this level of tracking what happens over time is impossible.

A branch for this change has been in and out of development for close to three years, and we have had a version of it in production for quite some time. After discussion at the Hack-a-Way 2016, it was generally agreed that keeping the current timestamp and also implementing the other two would be the best path forward for both feature support and compatibility. Hekman Library strongly believes this should be completed if possible before any other significant billing changes, as it is likely to have an affect on how we process most transactions.

• Concept: The standard billing statement view is overly verbose and disjointed.
• Relevant Bugs: https://bugs.launchpad.net/evergreen/+bug/1648232
• Completion (est.): 40%

A checkout/billing transaction is a sequence of events usually a string of billings followed by a string of payments. In these cases, our current view works fine, but we know there are many variations where the events become interspersed in unusual ways, and where adjustments must be considered in addition to payments. In these cases, the current display of two separate lists sorted only by accrual date can be difficult to understand.

The display could be much improved if patterned after more typical banking or service statements. The display would be a single unified list of events ordered by date applied (as implemented in step 1), not date of accrual. Adjustments would not be characterized as “payments” but rather both payments and adjustments would be characterized as “credits”. As they would often group naturally when ordered by date applied, billings and adjustments in particular could be effectively grouped into a single-line summary if desired. While the ultimate goal here is purely improved UI, we may wish to also change some of the code and data structures to better align with these goals.

More details re: Payments vs. Credits TBD

TBD