FOLIO DCB Configuration

Used at the supplying library to identify the borrowing patron group.

Virtual patron records are automatically generated via FOLIO DCB API in the supplying library when a request is created by OpenRS.

Virtual patron groups are used in circulation rules when the item is loaned to the virtual patron. A loan to the virtual patron results from a checkout to the patron at the borrowing library.

Patron group mapping is configured via DCB Admin Module to see how patron group mapping works. Tim Auger

Used at the borrowing library to identify the supplier material type.

Virtual item records are automatically generated via FOLIO DCB API in the borrowing library when a request is created by OpenRS.

Virtual material types are used in circulation rules when the item is loan to the patron. A loan to the patron results in a checkout ot the patron at the borrowing library.

Material type mapping is configured via DCB Admin Module to see how material type mapping works. Tim Auger

Used when supplying and borrowing. The syntax for each are as follows:

lending role 

• virtual patron group(s) | local material type or loan type | effective location (optional)

• loan policy, request policy (no recalls)
• no patron notices, no fees/fines 

borrowing role

• Local patron group(s) | virtual material type(s) | "DCB" (all virtual item records contain this location)

• loan policy, request policy (no pages, no recalls), patron notices, fees/fines

pickup role (as borrower at non-borrower pickup location)

• virtual patron group(s) | virtual material type(s) | "DCB" (all virtual item records contain this location)
• loan policy, request policy (no recalls)
• no patron notices, no fees/fines

FOLIO DCB uses the same staff slips and tokens as FOLIO circulation staff slips.

The requestservicePointPickup token is used to print the dcb pickup service point (see above) associated with the request. 

These service points are created automatically by the FOLIO supplier when it receives an incoming DCB request. 

Represents the pickup location of a member library. Prints on staff pick slips for operational purposes. 

The location "DCB" is automatically created by FOLIO when the tenant is enabled for OpenRS.

This location is defined at each level of the FOLIO location hierarchy: 

• DCB institution
• DCB campus
• DCB library
• DCB location

The DCB umbrella instance + holding record is automatically created by FOLIO when the tenant is enabled for OpenRS.

This allows for FOLIO to leverage the necessary architecture to allow for all DCB functionality to integrate seamlessly in FOLIO. 

DCB loan type

https://gil.folio.ebsco.com/settings/inventory/loantypes

Status is always "Available" or "Unavailable".  Currently, this approximates whether or not the item can be requested but it's not a perfect overlap. This needs both definition and reconciliation.

A document that elaborates on the display behavior for instances and items in the DCB union catalog, can be found here.

Patrons have two paths to authenticate in OpenRS. 1) Select the avatar in the upper right corner of the screen where the user will be prompted to "sign-in" or 2) Click on "place hold" button underneath the instance title. 

In both cases, if the patron has not already authenticated in the current browser session, they will be prompted for their institutional affiliation. From there, they will be prompted for their credentials. OpenRS supports both SSL and native ILS authentication (e.g. barcode and PIN).

Authentication is performed against the ILS. Patron record lookups are always against the ILS/LMS. No patron data is stored in DCB.

After the patron is authenticated, the patron is prompted to select a pickup location and then click on the "place hold" button. After that, you will see a spinning circle and, in the background DCB executes RTAC again to acquire the latest state information from the ILS/LMS' with items.

A document that elaborates on the behavior for instances and items in the DCB union catalog, can be found here.

As the supplier, the Requests app is where to start. All DCB transactions are of request type "page" and, via FOLIO, always have the same requester name of "DcbSystem, undefined." The requester barcode, however, is specific to the patron library. This acts as the unique identifier for library staff to communicate with borrowing library patrons when circulation exceptions occur (e.g. lost book).

OpenRS (a.k.a virtual) patron groups are the same in every FOLIO library and there are corresponding patron groups in every member library system. Regardless of the type of ILS/LMS, the DCB performs the mapping to translate equivalents to each library. (see mappings under the DCB Admin section below).

Every pickup location at other member libraries are represented as "Pickup service points". These can be referred to as "virtual" service points since these pickup locations are derived from the borrowing library. These are generated on-the-fly when that pickup location is newly introduced to a tenant and then reused for subsequent requests for that virtual pickup location. In Q CSP5, these service points will also automatically link to the default DCB calendar.

No configuration needed. Automatically generated.

Demo when Polaris/Sierra libraries are involved

Only the borrowing patron should receive patron notices. Is MCO aware of the possibility of customizing notices for OpenRS borrowing?

I would assume MCO since they have the keys to the kingdom and/or a trusted delegate. 

• Need to confirm with MCO that they can create loan policies
• Also, need to confirm with Tim
• Also, the creation of locations. Can we automate?

Each FOLIO member tenant will need standard policies (loan, overdue fine, lost item fee, patron notice, request) created for each loan period for OpenRS transactions. Has MCO determined what these policies should contain? Who will create the 5 policies in each member tenant?

MCO is planning to maintain their existing policies. I would assume MCO would either do it themselves or assign it to their member libraries.

• Need to confirm with MCO that they can create loan policies

FOLIO allows the use of multiple locations as criteria (connected with an implied “OR”) in a single circulation rule, which may lower the priority of possible development around wildcarding (to parallel Sierra’s feature). Once the location records exist in a FOLIO member tenant, a shared list of locations can be pasted into each tenant’s circulation rules, followed by removing that site’s location from the list. Who will create the circulation rules for lending (at least one per different loan period) in each member tenant? (The patron notice policy for lending transactions will not be set to send notices.)

I was planning to create a template and then have MCO figure out how they want to populate in each system.

Every FOLIO member tenant needs patron groups along the lines of “OpenRS long” and “OpenRS short.” Who decides how these will be named? Who will create them? When will we know if MCO has approved this smaller number of loan periods than what they were hoping for?

MCO should decide. I kickstarted the process this morning with Scott Peterson. 

The circulation rules for borrowing in each FOLIO member tenant will use the borrowing library’s existing patron groups, in conjunction with an OpenRS location, to apply the appropriate sets of circulation policies. (Did I get that right?) Who will create the circulation policies and circulation rules for borrowing in each member tenant?

Great question. I will volunteer for manual inspection duties. 

An OpenRS service point specific to the lending library will be created automatically in the borrowing library’s member tenant. If FOLIO allows circulation transactions to happen without a calendar assigned to the corresponding service point (Brooks Travis, can you confirm?), then OpenRS can simply approximate the calendar’s function by padding due dates (e.g., a 7-day loan might actually be given 10 days). Tim is going to raise this with Molly. Who will notify MCO of this functionality workaround?

Brooks, "No, there must be a valid calendar assigned to the service point to create a loan transaction there." 

Are DCB transactions written to CIRCLOG? 

Yes. 

What is this product called?