This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Additional topics (Resource Access)

1: Fees and fines
2: Loans

In addition to workflows that take place in a single app, library staff will also want to know about workflows that cross multiple apps, such as managing fees and fines, and managing loans and circulation rules together.

1 - Fees and fines

FOLIO allows libraries to charge fees and fines to patron library accounts. Charges can be for various reasons like room rentals; overdue return of a book; or replacing an item that the patron never returned. In FOLIO these are generally categorized together as Fees and fines or Fees/fines.

Libraries can charge fees/fines manually or automatically.

Automatic fines fall in three categories:

Lost item fee
Lost item processing fee
Overdue fine

They are charged automatically by FOLIO when items are loaned and not returned on time, according to the loan’s overdue policy and lost item policy.

Manual fees/fines, by contrast, are set up as categories in Settings > Users. They can be used for a wide variety of library charges, such as replacing a damaged item, renting a facility, or paying for a borrower card. Manual charges are always connected to a specific patron; they may be connected to a library item, but they are not connected to a library loan.

Fee/fine data structures

In FOLIO, fee/fine information is stored in two related objects: accounts and actions.

An account is the parent object. When a fee/fine is charged, an account object is always created.

An action is the child object where a transaction on an account is stored.

One account will have one or more actions associated with it.

Example: A patron does not return a book

Suppose Julia Smith is a patron at Normal University Library. She borrows a book and fails to return it to the library before it ages to lost.

When the item ages to lost, Julia is charged $100 as a set cost lost item fee, and $25 as a lost item processing fee.

The $100 replacement fee and $25 processing fee are each separate accounts charged to Julia.

Suppose that Julia can’t return the book and decides to pay for the item. She comes into the library and pays $50 in cash. For the $100 replacement fee, the library elects to waive $75 and accept $25 in payment. They apply the other $25 to pay her processing fee.

In FOLIO, the underlying account and action data would appear as follows.

Account #1: This represents the $100 charge to Julia as the set cost lost item fee. There would be three associated actions:

Action 1 represents the initial charge to Julia, with an action type in the underlying data of “Outstanding.” The action type in the user interface displays as “Lost item fee.” At this point, the account has a status of “Open.”
Action 2 represents Julia paying $25, with an action type of “Paid partially.”
Action 3 represents the library waiving the remaining $75, with an action type of “Waived partially.” When Action 3 is applied, the status of the account becomes Closed.

The Library could choose to waive the $75 first and then mark $25 as paid, in which case action 2 and action 3 would flip in order, but the result would still be the same - paying and closing the account, closing the loan, and changing the item status to Lost and paid.

Account #2: This represents the $25 processing fee, and it has two associated actions.

Action 1 represents the $25 processing fee charge, with an action type of “Outstanding” in the underlying data. The action type in the User Interface would display as “Lost item processing fee.”
Action 2 represents the library accepting $25 in cash to pay the fee, with an action type of “Paid fully.” When Action 2 is applied, the status of the account would become Closed.

Fee/fine owners

In FOLIO, a fee/fine owner represents the agent or office that manages fines for FOLIO transactions.

If you plan to charge any fines, you need to set up at least one fee/fine owner. FOLIO does not require that a fee/fine owner represent a specific office or part of a library system. A fee/fine owner could represent an individual, a specific office, or a specific library.

Fee/fine owners are configured in Settings > Users > Fee/fine > Owners

FOLIO libraries should configure a fee/fine owner for every service point in their FOLIO tenant, even if they don’t expect items attached to a particular service point to be loaned and generate fines. This is because if such a loan does occur, and no fee/fine owner is attached to the service point, the fine transaction will fail. Libraries may wish to create one fee/fine owner to attach to those service points as a backup in case fine transactions occur.

How are fee/fine owners connected to locations?

Most libraries want to collect overdue and lost fines according to an item’s owning location, so FOLIO uses the item’s location to determine which fee/fine owner to link to the fine. FOLIO does this by looking up the primary service point for the item location, and then looking up the fee/fine owner for that service point.

For an overdue fine, FOLIO uses an item’s effective location to determine the fee/fine owner.

For a lost item fee or lost item processing fee, FOLIO uses the item permanent location to determine the fee/fine owner. If the item permanent location is not set, FOLIO uses the permanent holdings location instead.

Fines always accrue this way even if an item’s location is not part of the circulation rule that was used for the loan that accrued a fine.

Example: accruing lost item fines to fee/fine owners

Julia Smith wants to borrow a book that is on the shelf at the Science Library, for pickup at the Law Library.

The book’s location information looks like this:

Item temporary location: empty
Item permanent location: empty
Holdings temporary location: empty
Holdings permanent location: “Science Library Stacks”
Item effective location: “Science Library Stacks”

Julie borrows the book from the Law Library service point and doesn’t return it. The item ages to lost, with a $100 set cost lost item fee and a $25 lost item processing fee.

When the item is aged to lost:

FOLIO first checks the item record for an item permanent location.
Since that value isn’t set, FOLIO next checks the holdings permanent location and finds the value “Science Library Stacks.”
FOLIO then checks the location record for “Science Library Stacks” and finds that the location has a primary service point of “Science Library Desk”.
Finally, FOLIO checks the fee/fine owner records for the service point “Science Library Desk” and finds it connected to the fee/fine owner “Science and Engineering Business Office”.

FOLIO charges both the $100 lost item fee and the $25 lost item processing fee and associates them to “Science and Engineering Business Office” as the owner.

Fee/fine notices

Notices function differently for fees/fines that are charged manually, versus fees/fines that are charged automatically.

Manual fee/fine notices

For a manual fee/fine, you have two types of notices that you can use - the charge notice and the action notice.

You can create templates for both types of notices in Settings>Circulation>Patron Notices>Patron notice templates. For a charge notice, choose the notice category “Manual fee/fine charge.” For an action notice, choose “Manual fee/fine action (pay, waive, refund, transfer, or cancel/error)”.

In Settings>Users>Fee/fine>Manual charges, you can select the appropriate fee/fine owner, and associate a charge notice and an action notice to that manual charge. You can select default charge and/or action notice templates for the owner, or specify different charge notice templates for individual fee/fine types.

When you create a manual charge on a patron’s account, or apply an action to an existing charge, if there is an associated notice template, a checkbox option will allow you to choose if the patron should be notified.

Automatic fee/fine notices

Notices for automatic fees/fines are determined by the associated circulation rule.

The notice policy of an item determines whether patrons will be sent fee/fine notices for overdue or lost item charges..

Overdue fine, returned and Overdue fine, renewed notices always bundle multiple fees/fines. In both cases, the associated template must include the {{#feeCharges}} {{/feeCharges}} token for multiple loans.

Overdue fine, returned: if you choose the Send after option, every patron notice will include all open overdue fines.
Overdue fine, renewed: if you choose the Send after option, each renew action will send separate patron notices.

You can send Lost item fee(s) charged notices throughout the day (typically processed every five minutes, with a separate notice for each fee/fine charged). You can also choose to bunch and send them overnight in one email (processed at 11:59pm). See Settings > Circulation > Fee/ fine notices triggering events.

Send overnight is good for long-term loans, while Send throughout the day is a good option for short-term loans. If you choose Send overnight then the associated template must include the {{#feeCharges}} {{/feeCharges}} token for multiple loans. If you choose Send throughout the day then the associated template must not include the {{#feeCharges}} {{/feeCharges}} token for multiple loans. Lost item fee(s) charged notices will be sent for both set cost and actual cost fees/fines and any applicable processing fees.

Lost item returned - fee(s) adjusted notices are always sent when the event is triggered, i.e. when the lost item is checked in. Lost item returned - fee(s) adjusted notices will be sent for both set cost and actual cost fees/fines, and any applicable processing fees.

How are overdue and overdue recall fees/fines calculated?

FOLIO’s fee/fine system is very dynamic and allows for many different configuration options of loan length and fee/fine settings. It can be helpful to know how the underlying logic works when FOLIO computes an overdue or overdue recall fine amount.

The factors that are used when calculating overdue fines are

The loaning service point calendar
Whether there is a grace period for a late returned, as defined in the loan policy
The stated overdue charge, as defined in the overdue policy
Whether overdue fines should be charged when the service desk is closed, as defined in the overdue policy

Because you can define fine rates and loan lengths in different intervals - minutes, hours, days, weeks or months - FOLIO’s approach is to take the length of time an item was overdue, convert it to minutes, and then compare that date/time to the fine interval - also in minutes - to determine how much to charge. This is fairly simple when a library charges fines for all hours, but can become much more complicated when charging fines only when an associated service point is open.

Note that FOLIO does not do calculations for overdue fees until the overdue or overdue recalled item is returned. Use reminder fees to have overdue items billed, and overdue notices sent, when an item becomes overdue.

Example: A patron returns an overdue item at a 24/7 service point

Suppose a patron borrows an item that has a three hour loan period, with an overdue charge of $3/day. They borrow the item at 2 PM on September 1. The item is due back at 5 PM on September 1, but they don’t return it until 6 PM on September 2nd.

The factors that are used in the overdue fine calculation include:

The loaning service point calendar - in this example, suppose the service point is open 24/7
The stated overdue charge, defined in the overdue policy - in this example, $3/day
Whether there is a grace period for a late return, defined in the loan policy - in this example, suppose there is no grace period
Whether they should charge the overdue fine during closed hours, defined in the overdue policy - in this example, suppose it is Yes

So, once the item is returned, FOLIO computes the overdue fine like this:

The item was overdue by one day and one hour - 25 hours - which it then converts to minutes - 1500 minutes
The fee/fine rate is $3/day. There are 1440 minutes in a day, so it’s $3/1440 minutes.
FOLIO computes the number of time “units” that the item was overdue for - in this case, dividing 1500/1440 = ~1.07 “units” of overdue time.
FOLIO rounds the number of overdue time “units” up to the next integer - in this case, 2.
FOLIO multiplies the number of overdue time “units” by the amount of the fine per interval - 3 - to get a total fine of $6.00

Example: A patron returns an overdue item at a service point that closes overnight

Suppose a patron borrows an item that has a seven day loan period, with an overdue fine of $3/day. They borrow the item at 2 PM on May 1st. The item is due back at 11:59:59 PM on May 8th. The patron returns the item at 2 PM on May 11th.

The factors that are used in the overdue fine calculation include:

The loaning service point calendar - in this example, suppose the service point is open 8 AM to midnight from May 1st to May 11th.
The stated overdue charge, defined in the overdue policy - in this example, $3/day
Whether there is a grace period for a late return, defined in the loan policy - in this example, a grace period of one day.
Whether they should charge the overdue fine during closed hours, defined in the overdue policy - in this example, that option is set to No.

So, once the item is returned, FOLIO computes the overdue fine like this:

The item was overdue by 2 days and 14 hours strictly looking at the calendar. That is 62 hours, which is 3720 minutes.
There is a grace period, but because the grace period is one day / 1440 minutes, and the item was returned after the grace period, the grace period does not factor into the calculation.
FOLIO sees that the overdue policy says to not charge overdue fines during closed hours. The associated loaning service point calendar shows it closed from midnight to 8 AM on three relevant days - the morning of the 9th, 10th, and 11th. The closed period is 8 hours each day - so 24 hours total, or 1440 minutes.
FOLIO subtracts the closed minutes from the total overdue period - 3720 - 1440 = 2280 minutes. That is the amount of overdue time FOLIO will charge for.
The fine rate is $3/day, or $3/1440 minutes. FOLIO computes the number of time “units” the item was overdue for - 2280/1440 = ~1.58 “units” of overdue time.
FOLIO rounds that up to the next integer - 2 - and charges for 2 intervals. So it would be 2 * 3 = 6, for a $6 fine.

It is important to notice that the patron was charged for 2 days even though the item was returned on the 3rd day after it became overdue.

There is development planned to better handle calculating fines for closed periods, but it is not currently scheduled.

Reminder fees

Reminder fees differ from overdue fines in that reminder fees are billed when an item becomes overdue, whereas overdue fines are billed when the item is returned.

A Reminder fee example

Sequence	Interval	Frequency	After	Fee	Notice method	Notice template	Block template
1	0	Day(s)	Overdue	3	Email	1st reminder	noblock
2	3	Day(s)	Previous reminder	3	Email	2nd reminder	noblock
3	3	Day(s)	Previous reminder	6	Email	3rd reminder	noblock

Preconditions:

Notices are sent out once per day (shortly after midnight).
An item with the associated reminder fee policy in the above example becomes overdue at 11:59 PM on Monday.
The item is not returned to the library and the loan is not renewed.

Reminder process:

The first sequence will create a first reminder with an email using the selected notice template. The email is sent out shortly after midnight on the first day after the overdue date (12:05 AM on Tuesday in the example). A 3.00 fee is charged.
The second sequence will create a second reminder with an email using the selected notice template. The email is sent out three plus one equals four days after the previous reminder (Saturday in the example). A 3.00 fee is charged.
The third sequence will create a third reminder with an email using the selected notice template. The email is sent out three plus one equals four days after the previous reminder (Wednesday in the example). A 6.00 fee is charged.

Reminder fee examples with closed days

Create on closed days set to Yes

A reminder fee policy has Create on closed days set to Yes, and the following schedule of fees:

Sequence	Interval	Frequency	After	Fee	Notice method	Notice template	Block template
1	0	Day(s)	Overdue	3	Email	1st reminder	noblock

Preconditions:

Notices are sent out once per day (shortly after midnight).
The calendar of the service point where the item is checked out is open on Monday, closed all day Tuesday, and open on Wednesday, Thursday and Friday.
An item with the associated reminder fee policy in the above example becomes overdue at 11:59 PM on Tuesday.
The item is not returned to the library and the loan is not renewed.

Reminder process:

The sequence will create a reminder with an email using the “1st reminder” notice template. The email is sent out shortly after midnight on Wednesday. A 3.00 fee is charged.

Create on closed days set to No

A reminder fee policy has Create on closed days set to No, and the following schedule of fees:

Sequence	Interval	Frequency	After	Fee	Notice method	Notice template	Block template
1	0	Day(s)	Overdue	3	Email	1st reminder	noblock

Preconditions:

Notices are sent out once per day (shortly after midnight).
The calendar of the service point where the item is checked out is open on Monday, closed all day Tuesday, and open on Wednesday, Thursday and Friday.
An item with the associated reminder fee policy in the above example becomes overdue at 11:59 PM on Tuesday.
The item is not returned to the library and the loan is not renewed.

Reminder process:

Because the service point is closed on Tuesday, no reminder fee is created on Tuesday. The 1st reminder email is sent out shortly after midnight on Thursday. A 3.00 fee is charged.

What happens to a loan when the fine is resolved?

When an item is declared lost, or an item ages to lost, the associated loan remains open, whether it is a set cost or actual cost fee/fine.

If the item is returned, and all associated fees/fines are removed, the loan is closed and the item’s status changes to either “Available” or “In Transit”, depending on where it was returned.

If the library resolves all fees/fines via payment, cancellation, or waiving, FOLIO automatically closes the fee/fine, closes the loan, and changes the item’s status to Lost and paid, even if no money is actually accepted by the library.

How should I configure our lost item rules if I want an item to age to lost but I want to be able to decide whether the patron should be charged?

Some libraries have guidelines where they want items to age to lost, but they don’t want to assess a monetary penalty - for example, if they are not able to charge faculty, but they still want faculty borrowing to be blocked because lost items were not returned.

If you want FOLIO to age items to lost but not charge a fine, the recommendation is to use a lost item policy that charges Actual cost and does not charge a lost item processing fee.

When the item ages to lost, the loan remains open, the item has a status of Aged to lost, and no fines are charged. The loan can remain in this state for as long as your library defines it in the setting For lost items not charged a fee/fine, close the loan after in the lost item policy.

If you wish to resolve the loan without charging the patron a fine, go to the Lost items requiring actual cost pane in the Users app. Locate the fine transaction, and choose Do not bill in the actions menu. That will close the loan and move the item to a status of Lost and paid without charging the patron.

What happens to a fine if the item record is deleted?

An item can be deleted even if an unpaid fee/fine is attached to the item record. This is a known issue, but development to address this has not yet been scheduled.

If an item is deleted, the underlying account record will remain. Deleting an item does not delete a fee/fine, and the fine record includes some item information stored directly, such as title, barcode, and item effective location. However, you will not be able to see the fine in the FOLIO user interface; instead you will see an error message.

Because of this issue, we recommend that libraries do not delete items with attached fees/fines. Checking for attached records can be done with a reporting or API query tool.

If you are using an API tool like Postman, a query like this will work, sent to your tenant instance of Okapi:

GET /accounts?query=itemId=="[Insert item UUID]"&limit=1000

Lost items - charging set cost versus actual cost

FOLIO defines two types of automated fine charging: Set cost and Actual cost.

For Set cost charges, libraries specify a standard charge for a lost item in the associated lost item policy, and FOLIO charges the patron that amount when the item is declared lost or ages to lost.

For Actual cost charges, the item ages to lost automatically, but the library must specify the amount to charge the patron manually. In the Users app, there is a reporting view that lists items that have aged to lost and need to have a charge applied. Libraries can also choose to not charge the patron for the lost item by choosing “Do not bill” when processing the actual cost charge.

Note that if the lost policy has an associated processing fee, the processing fee will be charged when the item ages to lost, regardless of whether the policy uses set cost or actual cost.

Timing considerations for when an item ages to lost

FOLIO uses a system-managed process to age an item to a lost status and apply any associated charges. The process has two pieces to it. The first is a process that moves the item status from Checked out to Aged to lost. The second process applies any associated fees/fines

By default, FOLIO runs the Aged to lost process every thirty minutes, and the fines process five minutes later. Hosting providers may choose to change this schedule to meet a specific library’s needs.

Here is how aging an item to lost might look in practice. Note that this example also works for actual cost, but if the lost item policy is set to actual cost, the only charge that is automatically applied is the processing fee.

Example: A long-term loan ages to lost

Consider the following scenario:

A patron borrowed a book and never returned it.
The loan had a due date of May 1, 2022. Because the item has a fixed due date, the actual due date/time is May 1, 2022 at 11:59 PM.
The associated lost item policy says that the item ages to lost after 28 days. When that happens, the patron is charged a $100 set lost item fee, with no lost processing fee.

The “aged to lost” time counter would begin on May 2nd. The 28-day overdue period would end on May 29th at 11:59 PM

After 5/29 at 11:59 PM has passed, the next run of the Aged to lost process will change the item status to Aged to lost.
After the item status changes to Aged to lost, the next run of the fine process will charge any associated fines.

The timing might look something like this:

May 29th 11:59 PM - the age of the loan goes past the overdue time frame and becomes eligible to be aged to lost
May 30th 12:00 AM - the Aged to lost process begins and changes the item status to Aged to lost
May 30th 12:05 AM - the Aged to lost fee charging process begins, takes in the aged-to-lost loan information, and applies the $100 charge to the borrower’s library account

Both steps of this process can take time to run, so if you have a large number of loans waiting to be aged to lost, the timing on this may not be exact, and it may take longer to see all of the loans be processed. Delays depend on the number of loans your library has to process.

Example: A short-term loan goes lost

Suppose a patron borrows a laptop charger with a four hour loan time. They borrow the item at 2:05 PM, and it’s due at 6:05 PM. The library has a lost loan policy for chargers that says that you must bring it back within three hours of the due date/time or it will be declared lost, and the borrower will be charged $75.

If the patron doesn’t return the charger, it would be eligible to be aged to lost at 9:05 PM. The timing might look something like this:

9:00 PM - the Aged to lost begins, but there are no loans to process.
9:05 PM - the charger goes past the lost time frame and is able to be aged to lost
9:05 PM - the Aged to lost fee charging process begins, but there are no loans to process
9:30 PM - the Aged to lost process begins and changes the item status to aged to lost
9:35 PM - the Aged to lost fee charging process begins, takes in the aged to lost loan information, and applies the $75 charge.

So functionally that means that there is a time period between 9:05 PM and 9:35 PM (at the earliest) where an item may be past the expected time frame but still look like it is only overdue, or look like it has aged to lost but without the expected lost item fee.

2 - Loans

This section of the documentation contains links to external sites. Please be advised that these sites are not maintained by the FOLIO Documentation Group and may be aligned with a different FOLIO release.

Library staff manage patron loans in FOLIO through three primary apps - Check in, Check out, and Users. Staff also can view information about loans in the Circulation log and Inventory apps.

The terms of a loan - who can borrow, how long they can borrow the item for, whether it can be renewed, what notices patrons receive, and whether any charges are accrued if the item is late - are determined by the circulation rule that is applied when the item is loaned, renewed, or has a due date change.

Loans data structure

In FOLIO, a loan object contains specific information that supports circulation functions and reporting.

userId: The UUID of the patron who borrowed the item. If the loan is closed and anonymized, the userId is removed from the loan record.
proxyUserId: If the item is borrowed by someone on behalf of another borrower using FOLIO’s proxy function, the proxy’s UUID is stored.
itemId: The inventory UUID of the item that was loaned.
itemEffectiveLocationIdAtCheckOut: The effective location of the item when it was checked out.
status: The status of the loan - usually open or closed.
loanDate: The date/time the item was loaned.
dueDate: The date/time that the item is due back. This date can change if the item is successfully renewed, recalled, or if a FOLIO user changes the loan due date.
returnDate: If the item has been returned, this is the return date/time. Returning the item may or may not change the loan status to closed - it depends on whether a fee/fine was charged.
systemReturnDate: If the return was backdated, the return date is the backdated date/time, and the systemReturnDate is the actual date/time the item was returned in the Check in app.
action: The last action performed on a loan - values include declaredLost, renewed, renewedThroughOverride, checkedin, checkedout, checkedOutThroughOverride, recallrequested, holdrequested, claimedReturned, markedMissing, closedLoan.itemAgedToLost, dueDateChanged, checkedInReturnedByPatron, checkedInFoundByLibrary.
itemStatus: The last item status in relation to this loan. This may or may not be the item’s current status in Inventory. For example, if a loan has been checked back in and put in transit back to its home location, the loan itemStatus field is In transit, but the item in Inventory may be Checked out if the item has since been loaned to another patron.
renewalCount: The number of times the loan has been renewed.
loanPolicyId: The UUID for the applicable loan policy.
checkoutServicePointId: The UUID of the service point where the FOLIO user was logged in when the item was loaned to the patron.
checkinServicePointId: If the item has been returned, this is the UUID of the service point where the FOLIO user who returned the item was logged in.
patronGroupIdAtCheckout: The UUID of the patron’s patron group at the time of checkout.
dueDateChangedByRecall: This is a true/false value indicating if the item’s due date has been changed by a recall for another patron.
declaredLostDate: If the loan is declared lost, the date of that declaration is stored in this attribute.
claimedReturnedDate: If the loan has been marked claimed returned, the date it was marked claimed returned is stored in this attribute.
overdueFinePolicyId: The UUID for the associated overdue fine policy, assigned when the loan is created. It is not updated when the loan is renewed.
lostItemPolicyId: The UUID for the associated lost item policy, assigned when the loan is created. It is not updated when the loan is renewed.
agedToLostDelayedBilling: FOLIO declares an item lost, and then bills the patron, in separate processes. These attributes on the loan object support that process.

What does FOLIO consider a short-term loan? What is considered a long-term loan?

FOLIO treats loan activity differently depending on whether it is a short-term or a long-term loan. The distinction depends on the time interval of the loan.

If an item is loaned for minutes or hours, the loan is a short-term loan.
If an item is loaned for days, weeks, or months, the loan is a long-term loan.

Differences between the two types of loans include:

The time a loan is due. A short-term loan sets its due date based on the loan date/time and the loan policy; a long-term loan sets its due date based on the loan policy and the loan date, but the due time is always 11:59 PM.
- For example: suppose a patron borrows an item from a service point open 9 AM to 10 PM seven days a week. If they borrow the item at 11 AM on April 1st, and the loan policy says they can borrow it for 48 hours, it will be due at 11 AM on April 3rd. But, if the loan policy said they could borrow the item for 2 days, it would instead be due at 11:59 PM on April 3rd, even though the service point is closed.

When a loan is renewed, or a loan due date is changed, what circulation rule applies and what policies are used?

When a patron or FOLIO user requests to renew a loan, or a FOLIO user changes a loan’s due date, FOLIO reviews the circulation rule file and may do several things, depending on what it finds (and not necessarily in the order listed below).

FOLIO checks to see if the patron is blocked from renewal (either manually or automatically). If they are not blocked, the process can continue.
FOLIO checks the patron record to make sure the record is not inactive or expired. If the record is not inactive or expired, the process can continue.
FOLIO will find the loan policy that applies and use that policy to determine if or how the loan can be changed. If the circulation rule file hasn’t changed, and the patron and item information hasn’t changed, FOLIO will retrieve and apply the same loan policy used the last time the loan was created or updated.
No request policy updates occur, because request policies aren’t stored on the loan. Since request policies only apply before the loan is created, there is no reason to keep a reference on the loan record.
FOLIO will not update the associated overdue policy and lost item policy, because it could cause the patron to be liable for more money than they had expected when they first borrowed the item.
FOLIO will update scheduled notices. The notice policy UUID is not stored on the loan. Instead, FOLIO reads the applicable notice policy from the circulation rule, removes the previous notices, and then creates the appropriate notices to run on the new dates.
FOLIO will create an entry in the circulation log to show that the item was renewed, or that the due date changed.

Example: An undergraduate becomes a graduate student

Suppose Sofia Cruz is an undergraduate at Main University.

Main University has a circulation rule file that has different rules for patron groups. Main allows undergraduates to borrow books for 28 days with unlimited renewals, and allows graduate students to borrow books for 90 days with unlimited renewals. Two circulation rules in FOLIO make that happen:

g undergrad: l 28-day-loan r hold-only n standard-notice o standard-overdue i standard-lost
g grad-student: l 90-day-loan r allow-all n standard-notice o standard-overdue i standard-lost

Sofia’s FOLIO account has a user group of ‘undergrad’, so the first line in this rule applies. They are able to borrow books for a 28 day rolling loan with unlimited renewals.

Suppose Sofia borrows several books in February and continues to use them, so they continue renewing their loans. Over the summer, they start a graduate program at Main University, and the patron group on their FOLIO record changes from ‘undergrad’ to ‘grad-student’.

The next time Sofia renews their books, the second line of the circulation rule file applies:

g grad-student: l 90-day-loan r allow-all n standard-notice o standard-overdue i standard-lost

This is what FOLIO does when renewing Sofia’s items:

FOLIO checks the circulation rule file and determines that it should use the circ rule line that begins g grad-student ….
FOLIO updates the loan policy UUID stored on Sofia’s loans to the UUID for the policy 90-day-loan and gives Sofia the new, 90-day rolling loan period.
There is no request policy stored on the loan record, so nothing changes there.
The overdue policy ID and lost item policy ID are stored on the loan record, but they are not updated when the loan is renewed or has the due date changed. That’s because a new overdue or lost item policy could potentially mean the patron owed more money than they were expecting if the item became overdue or aged to lost.
FOLIO reads in the notice policy from the circ rule. FOLIO then creates the scheduled notices in the notice database according to the policy and deletes previously scheduled notices that now don’t need to be sent.

What happens with circulation rules and policies if you change item information after an item is loaned (e.g., change a loan type for an item that is checked out)?

If you change information about an item that is currently on loan, nothing happens to the loan record. The loan may change if the item is renewed or if the loan due date is changed, and the change in the item information means a different circulation rule applies. See When a loan is renewed, or a loan due date is changed, what circulation rule applies and what policies are used?

What happens in FOLIO when an item is checked in?

When an item is checked in in FOLIO, the following steps happen (not necessarily in this order).

FOLIO checks the item status.
If an item has a status of Available and is checked in at a service point assigned to its effective location, FOLIO will count it as in-house use.
If an item has a status of In transit, FOLIO will check the logged-in service point to see if it is the primary service point for the item’s effective location. If the logged-in service point does not match, the item status remains In transit. If the logged-in service point does match, FOLIO changes the item status to Available.
FOLIO checks the loan policy, overdue policy and lost item policy to determine if any actions need to be taken.
If the item is determined to be overdue but has not been recalled, FOLIO calculates overdue fines based on the associated policy, and applies them to the patron’s account if the fine is greater than zero.
If the item is recalled and overdue, FOLIO calculates overdue recall fines based on the associated policy, and applies them to the patron’s account if the fine is greater than zero.
If an item status is Declared lost or Aged to lost, FOLIO presents a warning message, and staff must select from the prompt to continue check in.
When check in proceeds, FOLIO then references the lost item policy to determine if any fees should be credited back to the patron, and applies them to the patron’s account.
If the associated notice policy to the loan says that any fee/fine notices should be sent, those notices are generated and sent.

How is in-house use tracked in FOLIO data?

FOLIO does not track an explicit data attribute for in-house use of an item. Instead, FOLIO considers an item to be used “in-house” based on how the item status changes when it is checked in. If the item has a status of “Available” and is checked in at a service point assigned to its effective location, FOLIO considers that to be in-house use.

There is currently no way to generate a report of in-house use with an in-app report. One way to get at in-house use data is to use a tool like Postman to query the FOLIO API to return check-in records. Sending a GET request to your FOLIO instance like this:

/check-in-storage/check-ins?query=itemStatusPriorToCheckIn==“Available”

will return check-in records for in-house use.

What happens if/when you delete a circulation policy?

Loan policy

You are prevented from deleting a loan policy through Settings > Circulation > Loan Policies if there are open loans associated with the loan policy.

Request policy

You cannot delete a request policy through Settings > Circulation > Request policies that is part of circulation rules.

Request policies are only referenced when a request is placed, and are not stored on a subsequent loan, so they are fairly simple to delete, with the recommendation that you review your circ rules first.

For example, suppose you need to delete the request policy allow-all. The recommendation is to review your existing circulation rules and replace any references to allow-all with another request policy. Once you’ve done that, you can delete ‘allow-all’ from Settings > Circulation > Request Policies.

Notice policy

You cannot delete a notice policy through Settings > Circulation > Patron notice policies that is part of circulation rules.

Notice policies are only referenced when a loan is created, renewed, or a due-date is changed. They are fairly simple to delete, with the recommendation that you remove references to them in your circulation rules first.

For example, suppose you need to delete the notice policy faculty-semester-notice. First, you would review your circulation rules and update any references to faculty-semester-notice with another notice policy. Once you’ve done that, you can delete faculty-semester-notice from Settings > Circulation > Patron notice policies.

Overdue policy

You are prevented from deleting an overdue fine policy through Settings > Circulation > Fee/Fine if there are open loans associated with the policy.

Lost item policy

You are prevented from deleting a lost item policy through Settings > Circulation > Fee/Fine if there are open loans associated with the policy.

What happens if/when you delete a circulation rule?

If you remove a circulation rule from your circulation rule file, nothing happens to existing loans that used that circulation rule.

If a user tries to renew a loan that would have been renewed with the circulation rule that was removed from the file, FOLIO will review the circ rules for another matching rule. If it does not find at least one other matching rule remaining in the file, it will use the fallback rule.

How does FOLIO work with self-check stations?

FOLIO supports SIP2, an industry standard protocol for connecting self-service stations to library systems.

Patron self-service systems can connect to FOLIO with SIP2 using FOLIO’s SIP2 edge module. Setting this up generally requires working with your FOLIO administrator and/or hosting provider.

More information on SIP2 configuration can be found in the edge module documentation in Github - https://github.com/folio-org/edge-sip2.

Common errors when loaning items

Error message: “Calendar timetable is absent for requested date”

When an item is loaned, FOLIO needs to be able to calculate the item’s due date. It uses information from the patron record, the loan policy, and the calendar for the service point where the library staff member is logged in.

The error message “Calendar timetable is absent for requested date” means that FOLIO can’t find calendar information up to and including the calculated due date of the item.

The first troubleshooting step is to review the calendar for the service point in Settings > Calendar to ensure that you have provided a calendar for the length of time necessary.

This error message can be confusing when you consider how due dates are truncated to a user’s expiration date. Suppose you have the following scenario:

A patron comes to the desk on July 1 and wants to borrow an item;
According to the circulation rules, the patron should get a due date of December 15th. However, the patron’s user account is set to expire on August 15th, so they can only borrow the book until August 14th.
The calendar for the service point where the check out is occurring has dates inputted until September 1.

The calculated due date of August 14th is inclusive of the calendar information stored in FOLIO. However, the checkout will still fail with “Calendar timetable is absent for requested date.”

That is because FOLIO first calculates the due date without considering the patron expiration, and then checks the patron expiration date to see if the item should be due sooner. So because there is no calendar information extending out to December 15th, FOLIO can’t do the full calculation and presents an error.