►User Management Reference Data> Calendar
The Calendar is required for Circulation.
The Calendar is where you enter the dates when the library is closed for holiday periods. This is usually an annual task. The dates should be entered as inclusive dates. This ensures that no items are calculated for return to the library during the holiday period, nor are fines calculated during this time.
It is possible to specify whether items which normally would be due for return during the holiday are returnable the day before the holiday starts or returnable after the holiday period. You can also determine whether items are due on the same day of the week as they are issued; this avoids the problem of having all vacation loans due back on a fixed date.
In the Calendar record you can specify whether or not:
The Calendar data you enter and save here will also be visible in the Location records (below the Opening times). The Holiday and Return date information is visible so that it helps libraries with verifying the closed days, holiday and loan terms configuration.
All Calendar settings are hierarchical. OLIB uses a “Global” (system-wide) calendar if there is no location specific calendar for the dates in question.
The global / system wide calendar is set for xmas and new year:
Holiday Period Fields | Example Data |
---|---|
Short Description | Global xm20 |
Long Description | Global System Christmas Holiday 2020 |
Start Date | 21-DEC-2020 |
End Date | 01-JAN-2021 |
Locatie | LibraryA |
Allow Return During? | |
Return Before? | Nee |
Return Same Day? | Ja |
Send Odues/Recalls? | Nee |
Generate Fines? | Nee |
Send Res. Held Notifications | Nee |
Another calendar exists for LibraryA covering the same dates but with
For the NULL values LibraryA inherits the settings in the Global calendar: OLIB would NOT send Odues/Recalls or generate Fines for LibraryA. However OLIB DOES send Res Held alerts for Location A.
Note: You only need to create another calendar for locations whose policy differs from the global setting.
If one particular library remains open during the closed period then a record is not required for that Location - you only need a calendar record for the locations that are closed and not the single one which remains open.
Fields | Description | ||||||
---|---|---|---|---|---|---|---|
Start Date | Select the date when the holiday period begins from the Calendar. Dates are inclusive. | ||||||
End Date | Select the date when the holiday period ends from the Calendar. Dates are inclusive. | ||||||
Locatie | Search and select the Location for which this calendar applies. To apply to all locations leave the Location field blank – OLIB will assume that all Locations are closed on those days. However, a record should be entered for each location if the closing dates for a holiday period are different for certain locations. | ||||||
Allow Return During? | If set to Yes, this means that OLIB can calculate the return date to fall during the holiday. | ||||||
Return Before? | Enter Yes if items are to be returned before the holiday period. Enter No if items are to be returned after the holiday period. This flag is to assist with managing return dates before and after vacations. | ||||||
Return Same Day? | If this is configured on your system it can be used to set the return dates of items due back before / after holidays to be the same day of the week that they were issued. Select Yes if required. | ||||||
Allow Issue To Exp. Date |
When an item is issued to a user and the user’s membership expiry date falls before the return date, if the expiry date falls during a location or global closed calendar period, Allow Issue To Exp. Date? is examined to determine what to set the return date to.
|
||||||
Send Odues/Recalls? | This is a yes/no field to indicate whether overdue and recall notices should be generated during this holiday period. If this field is not explicitly set to either Yes or No, it will be interpreted as Yes. For any existing calendar records, you should set this field to No if you do not want overdues and recalls to be generated during this holiday period. Send Odues/Recalls parameters are also present at Location level. |
||||||
Generate Fines? |
Yes/No. This makes it possible to distinguish between calendar and location closed days:
NB - this only works for normal loan fines. Short loan fines only refer to the closed days in the location record. |
||||||
Send Res. Held Notifications | By default Reservation Held alerts are not sent during holiday periods. Set this flag to Yes if you do want the Reservation Held alerts to be sent during holidays. If set to No or not set, the alerts are not sent. |
If the calendar record does not specify a location, then the rules will be applied to all locations throughout your OLIB system. This can be overridden for the rules itemised above, by creating a Calendar record for a specific location. However OLIB will not assign a return date during the Calendar period for any locations.
Fines can be waived for users at a single location for a specified period of time. It is likely you would create a new Calendar record for this which should:
For example, for a period of bad weather or industrial action, you may wish to waive fines accruing during that period of time.
When you view the Fine/Charge/Payment/Waive History of a User registered at that Location, who would have accrued charges during that period, a Transaction Type "Fine Waiver" is created, and the Charge/Pay/Waiver Type column shows the Calendar name:
Audit No | Tran Type | D/Cr | Generated On | Term. | Amount | O/S Amount | Paid | Waived | Copy Barc....OR Charge/Pay/WaiverType |
---|---|---|---|---|---|---|---|---|---|
104 | Fine Waiver | C | 27-MAR-2019 | Y | 10.00 | 0.00 | 10.00 | 0.00 | Weather-Fine Waiver Calendar(retrospective) |
99 | Ent. Fee | D | 11-MAR-2019 | Y | 10.00 | 0.00 | 0.00 | 10.00 | Ent. Fee |
Audit No 99 shows 10.00 in the Waived column; Audit No 104 is a Credit (C) to the account - 10.00 is shown in Paid and the Waiver Type / Calendar name is shown.
Note that the waiving applies to individual, possibly daily, portions of a fine as configured in the fine steps, and not necessarily the fine as a whole.