Circ Delay Intervals

A new feature in 7.7.19 is the ability to set Circulation Delay intervals for initial and recurring orders.

Because duplication cartridges include multiple titles, it can be easy to overwhelm patrons with too much all at once. Setting a delay interval ensures that cartridges will be spaced out. It doesn't replace Shipment Size or any of the other existing settings--it works along with them.

For example, if you set intervals of 7 and 0, a new patron with a cutoff of 3 and a shipment size of 1 would receive one cartridge a week for three weeks. After that, if they returned all three cartridges at once, they would receive one cartridge each day for three days.

Will you be using this new setting? Will you add a delay for initial cartridges, recurring cartridges, or both? Any questions about how it works? Chime in here!

Yes, those are "days between shipments until patron hits cutoff for the first time" and then days between shipments from then on.

For calendar service and a delay interval, in brief: the greater between the two will apply.

(The faint of heart may want to stop reading here.)

The longer, slightly complicated version:

If a patron has a calendar service profile (such as weekly), that works by creating a "next service date," once the patron has been served. KLAS will not attempt to serve the patron unless the next service date is current or past. For duplication service, it checks the delay interval in addition to the next service date, between every shipment.

If the initial delay is 7, the patron is on weekly service, it'll all work out pretty much the same: one week between each cartridge or shipment of cartridges. If the initial delay is 7, the patron is on monthly service, and they have a shipment of one and a max of 3: they will receive one cartridge per week for three weeks, then not again until the next month (and once at least one cartridge has been returned). After that, the delay switches from initial to recurring and the process continues.

A temporary complication: as we "fill in" all the complexities and figure out how best to accomplish Duplication Service on the programming side, calendar service is probably not working quite as reliably as it did with Physical. The reason for this is that we have gone from a single nightly run to separate processes to refill Service Queues, to create Duplication Orders, and (for Gutenberg) to push Duplication Orders over to the duplication appliance. Smoothing all this out, so everything fits together and handles all the potential scenarios correctly, is an ongoing process. Right now, we do not have the ideal part of the process updating the next service date, a left-over issue from before the cartridge recycle model was added. This is being corrected, but at the moment, calendar service may be a bit idiosyncratic about when that next service date is being updated.

So, there are a lot of things working together here. Hopefully this helps clear it up for you instead of confusing things further!