Outdated version (20.01.2023)

See now Folio-Wiki: https://wiki.folio.org/x/qjW-BQ

Proposals on claims for monographs

by UB Leipzig and SLUB Dresden

Table of content

• Introduction
• Description Jira-Tickets
• Description additional functions (mockups)
• Description existing elements and values

Introduction

• In German libraries, specific demands on the claimings of monographs exist, which are not yet completely available in Folio. Especially in big libraries manual claiming processes are not sufficient and must be assisted by batch or automatic functions.
• Example: The SLUB Dresden sends 500-700 claims per month.
• The aim of the presentation is to explain the necessary adjustments. To reach the aim, in the following sections possible existing elements, planned developments and missing elements and functions are described.
• Jira-tickets concerning the claiming process in Folio
• Functions, which should be implemented in Folio
• Elements and values, which are available in Folio, but might be modified

Description Jira-tickets�Create filter options for Claim details

• Description:
• The facets in the App Orders are extended by
• Claim (yes/no),
• Claim grace (by date range),
• Claim sent (by date range)
• https://issues.folio.org/browse/UIOR-321
• Questions:
• -
• Proposals:
• Additional facets
• claim number (Mahnstufe) for SLUB Dresden
• The CQL-search (exclusion of specific values, …) should be possible

Description Jira-tickets�Populate claiming interval in POL from Organization record

• Description:
• Each organization record may contain a Claiming interval in the Vendor information accordion. This interval should be retrieved and added to the POL so the user can verify the claiming interval for each order placed with that Vendor.
• https://issues.folio.org/browse/UIOR-396
• Questions:
• -
• Proposals:
• This information should be implemented in a new accordion “Claiming information” (-> See slide “Claiming setting / Claiming setting in POL - new accordion”).

Description Jira-tickets�Add claiming checkbox to POL details

• Description:
• Claiming is not required for all orders. This will allow the user to indicate whether it is needed for this order or not. (Must identify default behavior)
• https://issues.folio.org/browse/UIOR-397
• Questions:
• -
• Proposals:
• If the “Claiming setting” (-> see slides “Claiming settings”) is implemented, the relations to the checkbox in POL must be defined:
• The value of the POL-checkbox is derived from the checkbox in the template
• The value of the POL-checkbox is a superior indicator which overrules the checkbox in the “claiming settings” -> If this checkbox is changed, the value in the settings is not regarded.

Description Jira-tickets�Alert: Claim needed

• Description:
• User must be made aware of orders that may need to be claimed.
• https://issues.folio.org/browse/UIOR-398
• Questions:
• Is the screen shot in the ticket correct or is it the screen shot in UIOR-399?
• Proposals:
• Besides the “Expected receipt date”, the status of the order should be considered for the alert to prevent claiming of orders which are set from “open” to “pending” (-> See slide Description existing elements and values / App: Orders / “Status”).

Description Jira-tickets�View claiming information on POL

• Description:
• As users are making decisions about whether or not to claim orders. The system must capture that activity and display it on the POL.
• https://issues.folio.org/browse/UIOR-399
• Questions:
• -
• Proposals:
• It must be possible to show several claiming numbers and claiming processes in the POL (-> see slides “Claiming settings”).
• For each claim, the date on which the claim was triggered, must be available.

Description Jira-tickets�Share claim information

• Description:
• As users are making decisions about whether or not to claim material from orders. The system must capture that activity and display it on the POL. When user has made the decision to make a claim for a piece of material and a communication method has been defined the claim information should be sent to the vendor.
• https://issues.folio.org/browse/UIOR-498
• Questions:
• Is there more information? It is difficult to imagine the process.
• Proposals:
• There should be an automatic or batch-option. It would be cumbersome, if each claim has to be sent to the vendor manually (-> See slides: Batch function on “create claim action”).

Description Jira-tickets�Create claim action

• Description:
• User must be able to create actions related to a claim.
• Delay claim
• Send claim
• Claimed at vendor system
• Add response
• Close claim
• https://issues.folio.org/browse/UIOR-670
• Questions:
• -
• Proposals:
• There should be a batch-option. It would be cumbersome, if each claim has to be sent to the vendor manually (-> See slides: Batch function on “create claim action”).

Description additional functions�Claiming setting

• Description:
• In the claiming settings it is possible to configure claiming templates, as for example monograph purchase claiming, monograph deposit claiming, … These templates can be selected in the POL in the element claiming template
• Each template consists of the the following elements:
• claiming active (information, if a claim needs to be send)
• claiming number (configuration of the claiming numbers and its intervals)
• Questions:
• -
• Proposals:
• In each POL, the element “claiming setting” is necessary.
• It is possible to set “claiming setting” as mandatory element in which only one template can be chosen.
• For each claim action, the date has to be written in the order line to derive information for the following claims. (UIOR-670)

Description additional functions�Claiming setting / Monograph purchase

Description additional functions�Claiming setting / No claim

Description additional functions�Claiming setting / Claiming setting in POL - new accordion

Description additional functions�Claiming setting / Claiming setting in order-templates

Description additional functions�Batch function on “create claim action”

• Description:
• When claims are filtered, it should be possible to create claim actions on several POL simultaneously. �Otherwise, the claiming process is quite cumbersome.
• If necessary, CQL-Search should be implemented to enable exclusion of specific elements.
• The ticket “create claim action” (UIOR-670) must be regarded.
• How can the proposed actions be applied to several POL or all filtered POL?
• After sending the claims, the date has to be captured in the POL.
• The creation of claim actions is only allowed for specific persons.
• The options for exporting the result-list can/must be analysed.
• The suggestions in the following mockups can be adjusted.
• All POL must be aggregated by “vendor” and “claim number”
• Otherwise, each POL is send in an own letter/email

Description additional functions�Batch function on “create claim action” / Simple version

Description additional functions�Batch function on “create claim action” / Simple version

• Description:
• In the simple version, only a few actions are offered in the action box for the result list.
• “Start claiming process on result list” -> sending the claims to the vendor
• “Claim items report (CSV)” -> export of CSV-data to analyse and correct in Excel, …
• “Instanzen UUIDs” speichern -> export of UUID for reporting, …
• The actions of UIOR-670 are not implemented.

Description additional functions�Batch function on “create claim action” / Alternative version 1

Description additional functions�Batch function on “create claim action” / Alternative version 1

• Description:
• In the alternative version 1, all actions of UIOR-670 are offered in the action box for the result list
• Delay claim
• Send claim
• Claimed at vendor system
• Add response
• Close claim
• Additional actions:
• “Claim items report (CSV)” -> export of CSV-data to analyse and correct in Excel, …
• “Instanzen UUIDs” speichern -> export of UUID for reporting, …

​

Description additional functions�Batch function on “create claim action” / Alternative version 2

Description additional functions�Batch function on “create claim action” / Alternative version 2

• Description:
• In the alternative version 2, the link to the actions of UIOR-670 are offered in the action box
• “Create claim action (new window)”
• In the new “action window” the POL of the result list are shown not only one POL as in UIOR-670.
• Additional actions:
• “Start claiming process on result list” -> sending the claims to the vendor
• “Claim items report (CSV)” -> export of CSV-data to analyse and correct in Excel, …
• “Instanzen UUIDs” speichern -> export of UUID for reporting, …

​

Description additional functions�Batch function on “Sending claims”

• Description:
• In each POL, the mandatory element “Claim delivery method” is specified. The element should be configurable in the settings.
• email
• postal letter
• It is necessary to create PDF-files for sending
• It is necessary to send claims via email in Folio, as claims are sent to the users.
• The email-address can be derived from the vendors’ record.

Description additional functions�Batch function on “Sending claims”

​

Description existing elements and values�App: Orders / “Approval date”

• Description:
• The date when an order is opened and thus the order should be sent. This is the beginning of the potential claiming process.
• Questions:
• -
• Proposals:
• If “Approval date” is updated, the “Expected receipt date” has to be updated, too.

Description existing elements and values�App: Organisations / “Expected receipt interval”

• Description:
• Definition of the period after which the first claim needs to be sent (manually or automatically). Start of the period is the date on which an order has been sent or “Approval date” in Folio. �https://docs.folio.org/docs/acquisitions/organizations/#vendor-information
• Questions:
• -
• Proposals:
• This value should be used to calculate and populate the Orders' "Expected receipt date" automatically.

Description existing elements and values�App: Orders/POL / “Expected receipt date”

• Description:
• The date on which a claim needs to be sent, if the order did not arrive on the expected date. It consists of: “Approval date” + “Expected receipt interval”.
• Questions:
• Is “Expected receipt date” or “Receipt due” the correct element?�https://docs.folio.org/docs/acquisitions/orders/#physical-resource-details�https://issues.folio.org/browse/UIOR-398 -> “Expected receipt date” is already applied.
• Proposals:
• The value in “Expected receipt date” should be calculated and written automatically when an order is opened.
• This value must be updated, when “Approval Date” is updated by re-opening an order.

Description existing elements and values�App: Orders / “Status”

• Description:
• The status of an order indicates if a claim is necessary.
• Questions:
• -
• Demands:
• The status of the orders must be evaluable for the claiming process (UIOR-399 )
• Open -> orders are regarded in the claiming process
• Pending -> orders are not regarded in the claiming process
• Closed -> orders are not regarded in the claiming process