Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Loan: Aged to Lost using SET COST

Description

Aging items to lost is a process many larger libraries do in order to encourage patrons to return their overdue items. After an item is overdue a specified period of time (see 'Item aged to lost after <number> <interval>' in attached Lost Item Fee Policy), the library will age it to lost by changing the item Item Status to 'Aged to lost' and billing the patron lost item fee(s) per the Lost Item Fee Policy. When a patron receives a bill for a 'lost' item that is most likely just 6 weeks overdue, they usually return the item immediately.

Some libraries wait a week or so between notifying the patron of the upcoming charge for the aged to lost item and actually billing the patron, giving the patron time to return the very overdue item before a bill is cut. This is determined in the Lost Item Fee Policy setting 'Patron billed after aged to lost <number> <interval>'.

The patron may also be charged a lost item processing fee depending on the Lost Item Fee Policy setting 'Charge lost item process fee if item aged to lost by system?'

There are many user stories defining this features because after an item has a status of 'Aged to lost' the system needs to block checkout, renewal and all requests, take special action at check-in, etc.

The 'is defined by" user stories with a Status of DRAFT are user stories Holly copied over from 'Declared lost" but has not updated for 'Aged to lost' yet. The other users stories, which are directly related to aging an item to lost, are ready for development.

Attached zipped folder Lost Item Processing.zip contains mock-ups and in-progress requirements for this feature.

Priority

Labels

Fix versions

Development Team

Prokopovych

Assignee

Solution Architect

Parent

Parent Field Value

None

Parent Status

None

Attachments

3

blocks

defines

has to be done after

has to be done before

is blocked by

is defined by

relates to

Checklist

hide

TestRail: Results

Activity

Show:

(OLD ACCOUNT) Erin Nettifee June 30, 2020 at 4:31 PM

I'll defer to but I think CIRC-667 could be a migration need. Libraries will need to bring loans over from older systems that are in an aged to lost state.

(OLD ACCOUNT) Erin Nettifee June 30, 2020 at 4:30 PM

I don't know if it helps at all, but at least for non-short loans (e.g. due in days instead of hours,) libraries would only expect an aged to lost process to happen once a day. E.g., early morning, the system checks loans, ages them to lost, charges fines and executes notices.

I'm not sure about short loans though.

Marc Johnson June 30, 2020 at 4:07 PM

The most time consuming part is automatically age items to lost, and it would be great to have a spike before actual development for technical review and initial design.

I agree. With the way that FOLIO currently works, this might involve periodically checking every overdue loan in the system in case it has aged for too long (because each one could have a different tolerance depending upon the policy).

Depending upon the scalability requirements for this, I think the back end work could grow to be bigger than the 30 days suggested.

Cate Boerema June 30, 2020 at 1:49 PM

Thanks guys! This is really helpful for planning.

FYI. Also, did you see Bohdan's question above?

Sergiy Sergiyenko June 30, 2020 at 1:15 PM

Hi .

My pessimistic estimation corresponds to the existing one - XXL <30 days.

Bohdan Suprun June 30, 2020 at 10:13 AM

Hi ,

I'd say it is about 20-30 days (XXL). We already have the most complex parts of the process (assigning lost/overdue fines). The most time consuming part is automatically age items to lost, and it would be great to have a spike before actual development for technical review and initial design.

Rest of the stories should be quick (~3 story points), except CIRC-667 (is it really required? are we going to have an ability to age an item to lost manually?).

Cate Boerema June 30, 2020 at 8:31 AM

Hi and can you please tell me in the comments here what you would estimate this as if we were to do this on Core Functional (in t-shirt sizes)? As you can see, the estimates are currently very high because this feature is assigned to a different team. We are considering moving the feature to CF and would like to understand if the estimates would change and by how much.

Thanks much!

Holly Mistlebauer March 19, 2020 at 3:16 PM

Notes from November 2019 Resource Access SIG meeting...added for historical purposes...

Done

Details

Reporter

Potential Workaround

Holly: Libraries use the "aged to lost" process to prompt their patrons to return items that have been overdue for a long time (say 6 weeks). When a patron is notified that the item they have will be flagged as lost and they will need to pay $150, they usually bring the book back right away. Most of the time the library waits a week or so after they notify the patron to actually charge them the $150. Libraries that do this could query the database (or data warehouse?) for a list of items more than 6 weeks overdue and send out some type of notice and then bill the patrons a week later using the manual New Fee/Fine feature, but due to the volume this is not a reasonable workaround.

PO Rank

100

PO Ranking Note

This feature is ranked low because non-US libraries don't care about this. For US libraries like Chicago, Duke, and Lehigh this must be available at go-live.

Estimation Notes and Assumptions

Estimate is high because there is so much work to do to check the item status and block certain actions. Age to lost is also a batch process that has criteria to use in determining what to age to lost (rather than a button to push like with Declared Lost).

Front End Estimate

XXL < 30 days

Front End Estimator

Front-End Confidence factor

Medium

Back End Estimate

Jumbo: > 45 days

Back End Estimator

Rank: FLO (MVP Sum 2020)

R1

Rank: 5Colleges (Full Jul 2021)

R1

Rank: Cornell (Full Sum 2021)

R1

Rank: Chalmers (Impl Aut 2019)

R4

Rank: GBV (MVP Sum 2020)

R4

Rank: hbz (TBD)

R4

Rank: Hungary (MVP End 2020)

R1

Rank: TAMU (MVP Jan 2021)

R1

Rank: Chicago (MVP Sum 2020)

R1

Rank: Leipzig (ERM Aut 2019)

R5

Rank: MO State (MVP June 2020)

R1

Rank: U of AL (MVP Oct 2020)

R1

Rank: Leipzig (Full TBD)

R4

Rank: Lehigh (MVP Summer 2020)

R1

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs

Created January 18, 2018 at 9:45 PM
Updated February 9, 2022 at 6:00 PM
Resolved October 14, 2020 at 3:11 PM
TestRail: Cases
TestRail: Runs