...
For OpenRS to produce the expected results in FOLIO, every FOLIO tenant needs the following settings. Those labelled "Auto" are automatically created by FOLIO when the tenant is enabled for OpenRS; see example ticket "US1331136 - GALILEO: please enable modules needed for DCB."
| Type | Role | Usage | auto or manual | Examples | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Location | all | 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:
| Auto |
| ||||||||
| Patron Groups | supplier | 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 in the via DCB Admin Module to translate patron groups from one library/agency to a different library.^^need link to DCB pagesee how patron group mapping works. Tim Auger | Manual | |||||||||
| Material Types | borrower | 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.^^need link to DCB page Material type mapping is configured via DCB Admin Module to see how material type mapping works. Tim Auger | Manual | |||||||||
| Circulation Rules | borrower and supplier | Used when supplying and borrowing. The syntax for each are as follows by role. lending role
borrowing role
pickup role (as borrower at non-borrower pickup location)
| Manual | |||||||||
| Service Points | supplier | Represents the pickup location of a member library. Prints on staff pick slips for operational purposes. These service points are created automatically by the FOLIO supplier when it receives an incoming DCB request. | Auto | |||||||||
| DCB calendar | all | A DCB calendar is automatically created by FOLIO when the tenant is enabled for OpenRS. As part of the enabling process, each dcb service point is is linked to the DCB calendar. Latest changes can be found here:
| Auto | |||||||||
| Staff slips | all | 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. | Manual | |||||||||
| DCB instance record + holding | borrower | 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. | Auto | |||||||||
DCB loan type | The DCB loan type is automatically created by FOLIO when the tenant is enabled for OpenRS. | Auto | ||||||||||
| DCB cancellation reason | The DCB loan type is automatically created by FOLIO when the tenant is enabled for OpenRS. | Auto |
...
The DCB admin module is available to Consortium Central Office, EBSCO, and K-Int staff for on-boarding and support activities.
DCB admin STAGING for MOBIUS: https://libraries-dcb-hub-admin-scaffold-uat-git-staging-knowint.vercel.app/en-US
Currently, the "Requests" mode contains access to the lifecycle of all DCB transactions. This is a request and circulation troubleshooting tool for implementation specialist and support desk staff.
The remainder of the modes allow implementation specialists to define the systems and their agencies and corresponding shelving locations and pickup locations. There are also mappings for patron groups, material types and pickup locations to canonical DCB values.
Example:
- FOLIO patron group value "undergrad" is mapped to DCB canonical value "200"
...
| Requests |    |
| Audit | -- |
| Mappings |   |
Additional Resources
--
FOLIO
QnA
Potentially useful fodder between ICs and Tim Auger during original onboarding
| Question | Answer | Notes | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1. | OpenRS will create a virtual patron record for a specific patron in the borrowing FOLIO member tenant, without identifiable information. Will these be identified with a user type of “shadow,” or is that reserved for staff accounts? (Or maybe “system”?) | Not shadow accounts but "DCB" patrons with a very limited amount of data (DCB Patron Group, DCB Patron Barcode, DCB Library Code (aka agency code), DCB Transaction UUID). For more details on the relationship between entities, see the "Entity Relationship Diagram" section in DCB Integration. | No configuration needed. Automatically generated. | ||||||||
| 2. | Only the borrowing patron should receive patron notices. Is MCO aware of the possibility of customizing notices for OpenRS borrowing? | I have told MCO that they can customize notices for OpenRS borrowing but I've not gone into any detail about how to do it. | Important note – there is only one version of each type of staff slip. Need to inform MOBIUS so they decide whether or not to modify. | ||||||||
| 3. | Each FOLIO member tenant should have a location representing each other member library, under the DCB institution hierarchy. This needs to exist before circulation rules referencing those locations can be created. Who will create the locations in each member tenant? | I would assume MCO since they have the keys to the kingdom and/or a trusted delegate. |
| ||||||||
| 4. | 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. |
| ||||||||
| 5. | 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. | |||||||||
| 6. | 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. | |||||||||
| 7. | 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? | Correct. I'll create a template for the circ rules and then they can modify to suit their needs and copy into circ rules. It would be ideal if this process (and above processes) followed the standard FOLIO process. | |||||||||
| 8. | Each FOLIO member tenant’s circulation rules will need careful review to ensure that the combination of priority row, criteria used, and order of rule lines applies the OpenRS policies to the appropriate transactions. Who will do this review? | Great question. I will volunteer for manual inspection duties. | |||||||||
| 9. | 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 ( , 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." | |||||||||
| 10. | Are DCB transactions written to CIRCLOG? | Yes. | See | ||||||||
| 11. | What is this product called? | OpenRS DCB. OpenRS is the project namname. DCB is a model of Resource Sharing and the first piece of the OpenRS resource sharing portfolio. |
...