Auf dieser Seite werden vorhandene Tickets bezüglich der der Bestellmahnungen bewertet.
Proposal UB Leipzig and SLUB Dresden
Initial proposal on claims for monographs
Proposals on claims for monographs (Google-Präsentation)
https://docs.google.com/presentation/d/1bdp3qhsHSld5jpOtJSoHqdUWTWn_rDbBAZacEwJojz8/edit#slide=id.g118b3a95366_0_0 - Slides 03-10
Introduction
- In German libraries, specific demands on the claims 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 proposal 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
- Elements and values, which are available in Folio, but might be modified
- Functions, which should be implemented in Folio
Description Jira-tickets
UIOR-321 - Getting issue details... STATUS
- Proposals:
- Additional facets
- claim number (Mahnstufe) for SLUB Dresden
- The CQL-search (exclusion of specific values, …) should be possible
UIOR-396 - Getting issue details... STATUS
- Proposals:
- This information should be implemented in a new accordion “Claiming information”
(-> See /wiki/spaces/~hohmann/pages/3572651).
- This information should be implemented in a new accordion “Claiming information”
UIOR-397 - Getting issue details... STATUS
- Proposals:
- If the “Claiming setting” (-> see /wiki/spaces/~hohmann/pages/3572651) 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.
UIOR-398 - Getting issue details... STATUS
- 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”).
- 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”
UIOR-399 - Getting issue details... STATUS
- Proposals:
- It must be possible to show several claiming numbers and claiming processes in the POL
(-> see /wiki/spaces/~hohmann/pages/3572651). - For each claim, the date on which the claim was triggered, must be available.
UIOR-498 - Getting issue details... STATUS
- 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: /wiki/spaces/~hohmann/pages/3572653).
- There should be an automatic or batch-option. It would be cumbersome, if each claim has to be sent to the vendor manually
UIOR-670 - Getting issue details... STATUS
- Proposals:
- There should be a batch-option. It would be cumbersome, if each claim has to be sent to the vendor manually
(-> See /wiki/spaces/~hohmann/pages/3572653”).
- There should be a batch-option. It would be cumbersome, if each claim has to be sent to the vendor manually