FYI: as written up on the roadmap, libraries WILL be allowed to specify the yearly date. https://portal.productboard.com/iii/6-innovative-product-status-board-new/c/856-automate-moving-ytdcirc-to-lyrcirc-at-year-end-and-don-t-update-last-updated-date

I like this idea, but the Sierra Admin must have control over the scheduling of this action and/or disabling it altogether. I have a routine of taking an item record snapshot before and after the process every Jan 1 and these exports are very important for reporting performed later.

Thank you Lisa Bobis for writing up the idea!

Automating this function would be beneficial to all libraries and reduce staff time spent late at night waiting for the process to complete.

MEEP candidate July 2024

I'll join in with a YES for the automatic update and not changing the last updated date.
And as noted by others, the date chosen should be determined by the library.

I agree that automating is good but we need to choose the date for the update.

Automating would be nice, but not updating the last updated date when this is done would be great. We use last updated date for so many reports, and it skews them after YTDCIRC is updated.

Agree, automatic would be great but allow the library to determine when it occurs and whether the figures are added to LYRCIRC or replaced. We run an alternating process of clearing and adding.

We update this field in July not December. Automatic updating would be nice if libraries could set the date.

Automation of this process would be really great as would also the ideal of not changing the updated date. In our consortium, since the process is manual, I don't run this until I've created some of our monthly reports that use that updated date. So for us, its always been done the 3rd weekend in January. In regards to the updated date, at one time (maybe back to Millinnum - I don't remember exactly when). At one time, not updating this date had been reported as a bug which was later "fixed". Those of us who used it up until that time were caught off guard when that fix was implemented. At that time, there were several requests at that point to put back the old behavior. So it seems to me that over the years, some want the updated date to change and others don't so making it an option might be a better choice along with being able to set the time/date when the the process is run.

I agree with automating it on a date set by the library. Ours operates on a July 1 - June 30 fiscal year, so having it automate on July 1 would be ideal.

Having the option to automate this on a date set by the library would be great! It is frustrating to have to log in just for this task or train someone else to do it, if the fiscal year starts on a date the usual person doesn't work (weekend, vacation, etc.).

Also, having it done automatically by the system would reduce the chance of errors. We run the process on a list of items with either YTDCIRC or LYRCIRC stats, to reduce the number of items that have their last-updated date changed. However, one year someone made the list based on items with both YTDCIRC and LYRCIRC stats. By the time we realized what had happened, there was no way to fix it. That threw off our use of both fields for years.

It would be really useful to be able to automate this, to not have this depend on a Sierra administrator being at work on the first day of the year (and remembering to do it). Also, it would be useful to retain the last updated date and not have it changed by the YTD/LYCIRC process.

Automating would be great, but our fiscal year does not equal the calendar year. So should be customizable by the system.

In fact we would need to customize it differently for each member of our consortium. We have academic library years starting in July and public library years starting in January on the same server. It is a pain to have to do it manually for each library, but we do need to do them separately.

Making this an automatic process would be very helpful but make sure that each customer is able to select when that process occurs. We opt to handle these two fields on a fiscal instead of calendar year basis.