Questions about existing fields/functions (claiming process)

1. Is it planned that the value of the field “Expected receipt date” field in the app Orders is entered automatically when the order is opened and calculated by adding the value of the field “Expected receipt interval” in the app Organization to the date when the order is opened?

   • Open

     
   • Open

     

   • According to UIOR-396: Populate claiming interval in POL from Organization recordClosed the function is planned, but probably not yet available in Snapshot?

     • JR: Claiming is based on “receiving title” information in the Receiving app. When creating a piece in Receiving, the default expected date is the “expected receipt date” in the POL. With serials/ongoing orders, this expected date applies to the first date.

     • For serials with (more or less) predictable expected dates, the Serials app can be used to create receiving pieces with expected dates in the Receiving app.

     • For a piece to be set to “Late” in Receiving, “Claim active” must be true in the order line AND the receiving piece must have an expected date.

     • “Expected receipt interval” currently does not interact with other fields, and is merely informational. It can be used to estimate expected dates for receiving pieces, but the Serials app is where automatic predicting happens.

2. How is the value in the field “Claiming interval” in the app Orders applied?

   • Will the value be imported from the app Organizations for each order?

     • JR: The default Claiming interval from Organizations should be applied to each order line, but can be changed at the order line level.

3. When/How is the checkbox “Claiming active” activated?

   • Is the checkbox activated manually or automatically? 

     • JR: It is activated manually

   • Can a default value be defined, as envisaged in UIOR-397: Add claiming checkbox to POL detailsClosed ?

     • JR: It should be configurable in templates

 Example records in FOLIO-Snapshot:

• Order: https://folio-snapshot.dev.folio.org/orders/lines/view/baec48dd-1594-2712-be8f-de336bc83fcc

• Organization: https://folio-snapshot.dev.folio.org/organizations/view/f0fb6130-cdf1-11e8-a8d5-f2801f1b9fd1

Questions about proposals to enhance/improve fields/functions (claiming process)

Configuration of reminders/claiming letters

Definitions

The following definitions are intended to facilitate understanding of the following questions. 

• Claiming settings: Proposal to create a new section in the app Settings for the configuration of the claiming process. 

• Claiming level setup: Configuration of the claiming levels (for example the amount of claiming levels for each claiming level setup) for various specific use cases (e. g. purchase or depository). 

• Claiming level: Escalation stages with properties as for example the claiming interval for each level.

Questions

1. Can a new section “Claiming settings” (or with another label) be created in the app Settings for the configuration and management of claiming levels?  

   • See proposals with mock-ups: 03 Mahnstufen (Bestellmahnungen) - Funktionsanalyse

2. Can multiple claiming level setups be implemented in “Claiming settings” (e.g. for depository and purchase acquisition in the mock-ups)?

   • The claiming levels should be used in addition to the existing field “Claiming interval” in the app Orders, which should still be available - as the field is already applied and not all institutions might need claiming levels. 

   • Examples of Claiming levels per claiming setup:

     1. Claiming level setup 1 (purchase)

        1. Claiming level 1 : A days (1 - purchase)

        2. Claiming level 2 : B days (2 - purchase)

        3. …

     2. Claiming level setup 2 (depository)

        1. Claiming level 1 : Q days (1 - depository)

        2. Claiming level 2 : R days (2 - depository)

        3. …

     3. …

3. Can an additional integration of e-mail dispatch be implemented for each claiming level in order to adjust the text and claiming interval for each claiming level? The e-mail templates should be managed globally (see next section “E-Mail templates for sending orders and claims“).

   • Examples: 

     1. Claiming level setup 1 (purchase)

        1. Claiming level 1 : A days + e-mail-template (1 - purchase)

        2. Claiming level 2 : B days + e-mail-template (2 - purchase)

        3. …

     2. Claiming level setup 2 (depository)

        1. Claiming level 1 : Q days + e-mail-template (1 - depository)

        2. Claiming level 2 : R days + e-mail-template (2 - depository)

        3. …

     3. …

4. How and when are the reminders sent? 

   • Can the sending of the reminder be configured for each institution (see the previous questions 2 and 3)?

   • Can the reminder be sent both automatically and manually?

5. Wie/wo wird die derzeitige aktuell gültige Mahnstufe angezeigt?

6. How/where is the current valid claiming level displayed? 

   • Proposal: Creation of a new accordion for claiming information in the app Orders. 

     • See: 03 Mahnstufen (Bestellmahnungen) - Funktionsanalyse

   • Can this be combined with planned the activities in the app Receiving?

     • See:

       • 2023-09-12 Acquisitions Meeting notes

       • 2023-10-03 Acquisitions Meeting notes

   • Is the app Orders is a good place to merge claiming information from the apps Settings, Organizations and to disseminate the information to the app Receiving?

     • @André Hohmann Sep 18, 2024 : It seems as there will be an additional app for claiming (2024-09-10 Acquisitions Meeting notes). Therefore the question does need to be answered.

E-Mail templates for sending orders and claims

1. Global templates are required for order dispatch

   • Reason

     • Approximately 15,000 vendor data records are managed in the SLUB Dresden, thus e-mail-templates cannot be created and customized manually for each vendor. 

   •  Advantages

     • Future adjustments on the texts (salutation, formulations, ...) can be implemented globally

     • Unintentional deviations in the e-mail texts per vendor are avoided, for example due to natural variances where several employees are involved

2. Global templates are required for each claiming level and for each claiming level setup and not for every single vendor

   • Reason 

     • Approximately 15,000 vendor data records are managed in the SLUB Dresden, thus e-mail-templates cannot be created and customized manually for each vendor. 

   • Advantages

     • Future adjustments on the texts (salutation, formulations, ...) can be implemented globally for each use case

     • Unintentional deviations in the e-mail texts per vendor are avoided, for example due to natural variances where several employees are involved

Integration Details

1. Could several integration details be created for each vendor?

   1. JR: Multiple integrations are possible for each vendor. We plan to separate order integrations from claiming integrations (i.e. separate integrations for ordering and claiming are required), but we are also adding the ability to copy integrations to simplify that.

   2. Please see:

      1. UIORGS-441: Add Duplicate integration to organization integrationsOpen

      2. UIORGS-442: Add claiming to organization integration detailsOpen

2. If there are more then one integration details per vendor available:

   1. Could one of them be selected manually in each order?

      1. JR: We are evaluating the best approaches for this. Ideally it would be programmatic, based on location, custom field, or similar. Manual selection is also a possibility, but for large libraries, might be cumbersome.

      2. JR: Update - based on feedback from the SIG, it appears the preferred method is to apply integration based on account number.

   2. Could one of them be defined as default value in the order templates?

      1. JR: That is definitely a strong possibility.

Filter functionality

1. Can orders be filtered by the expected receipt date before dispatch? 

   1. Goal: It should be possible to manually change the expected delivery date in order to delay the reminder. 

   2. Note: There are mock-ups from Dennis Bridges that describe similar scenarios 

      1. 2023-09-12 Acquisitions Meeting notes

      2. 2023-10-03 Acquisitions Meeting notes

         1. JR: Delay claim functionality already exists. We are planning an interface to allow this in a dedicated claims space rather than having to go title-by-title

Related links

UXPROD-4274: Support claiming integration via EDIFACT order exportIn Progress

EDIFACT/Automated Claiming (Please note that the Miro link is a whiteboard/work in progress for mocks and consideration of approaches)