Uploaded image for project: 'mod-circulation'
  1. mod-circulation
  2. CIRC-717

BE - Declared lost item: check in (effect on fines/fees) - SET COST

    XMLWordPrintable

Details

    • Core: F - Sprint 88, Core: F - Sprint 89, Core: F - Sprint 90, Core: F - Sprint 91
    • 8
    • Prokopovych

    Description

      Background

      Holly was asked to split user story CIRC-717 (Backend: Declared lost: check in (effect on lost item fees) into 3 user stories to match the 3 ways in which a patron may have been charged a lost item fee. Please note that a patron may be charged a lost item fee 0-3 of these ways, so we need to check for all 3) -

      1. The Set cost from the Lost item fee policy, which results in a fee/fine record with a Fee/fine type of Lost item fee. Given that the Lost item processing fee is a "set cost" as well, it is included in this user story, as is charging an overdue fine: new user story is CIRC-717 (BE - Declared lost: check-in (effect on lost item fees) - SET COST)

      The Actual cost of the item, which is used if the Lost item fee policy setting Actual cost is turned on. After the actual cost is determined, the Fee/Fine Owner will enter a manual charge for the patron, creating a fee/fine record with a Fee/fine type that exists in the Manual charges table. The Fee/fine owner may be using a Fee/fine type that is "Shared" by all Fee/fine owners or one that exists for just that _Fee/fine owner -

      2. Read the Manual charges table for the Fee/fine owner in the fee/fine record to locate the Fee/fine type to Use for Actual Cost (e.g. Lost item fee for actual cost, Lost item fee - actual cost, Actual cost of lost item): new user story is CIRC-729 (BE - Declared lost: check in (effect on lost item fees) - SHARED ACTUAL COST)_

      3. Read the Manual Charges for the “Shared” Fee/fine owner in the fee/fine record to locate the Fee/fine type to Use for Actual Cost (e.g. Lost item fee for actual cost, Lost item fee - actual cost, Actual cost of lost item): new user story is CIRC-730 (BE - Declared lost: check in (effect on lost item fees) - FF OWNER ACTUAL COST)

      Scenarios

      DETERMINE IF LOST ITEM PROCESSING FEE AND/OR LOST ITEM FEE SHOULD BE CANCELLED AND/OR REFUNDED

      1. Scenario
        • Given an item with the status Declared lost, and a lost item fee policy for that item with "if lost item returned or renewed, remove lost item processing fee" set to Yes, and a lost item fee policy for that item with "No fees/fines shall be refunded if a lost item is returned more than X <intervals> late" with X > 0
        • When that item is checked in
        • Then:
          • Calculate number of intervals (e.g. 6 months) between when item was declared lost and today's date
            • If calculated number of intervals > "No fees/fines shall be refunded if a lost item is returned more than X <intervals> late"
              • No fees/fines are removed or refunds processed
            • Else
              • Go to CANCEL/REFUND LOST ITEM PROCESSING FEE
              • Go to CANCEL/REFUND LOST ITEM FEE
      2. Scenario
        • Given an item with the status Declared lost, and a lost item fee policy for that item with "if lost item returned or renewed, remove lost item processing fee" set to Yes, and a lost item fee policy for that item with "No fees/fines shall be refunded if a lost item is returned more than X <intervals> late" with X null
        • When that item is checked in
        • Then:
          • Go to CANCEL/REFUND LOST ITEM PROCESSING FEE
          • Go to CANCEL/REFUND LOST ITEM FEE
      3. Scenario
        • Given an item with the status Declared lost, and a lost item fee policy for that item with "if lost item returned or renewed, remove lost item processing fee" set to No
        • When that item is checked in
        • Then:
          • Go to CANCEL/REFUND LOST ITEM FEE (lost item processing fee will not be cancelled/removed)

      Now let's see if the patron should be charged an overdue fine (continue on to DETERMINE IF OVERDUE FINE SHOULD BE CHARGED)

      DETERMINE IF OVERDUE FINE SHOULD BE CHARGED

      1. Scenario
        • Given an item with the status Declared lost, and a Lost Item Fee Policy for that item with radio button set to "If lost item returned or renewed: Charge overdues based on returned date up to maximum (if applicable)" and a Lost Item Fee Policy for that item with "No fees/fines shall be refunded if a lost item is returned more than X <intervals> late" with X > 0
        • When that item is returned
        • Then:
          • Calculate number of intervals (e.g. 6 months) between when item was declared lost and today's date
            • If calculated number of intervals > "No fees/fines shall be refunded if a lost item is returned more than X <intervals> late"
              • Do not charge overdue fine
            • Else
              • Charge overdue fee by calling module created by CIRC-524 (this module is also called by the check in process and regular renewals to calculate overdue fines)
      2. Scenario
        • Given an item with the status Declared lost, and a Lost Item Fee Policy for that item with radio button set to "If lost item returned or renewed: Charge overdues based on returned date up to maximum (if applicable)" and a Lost Item Fee Policy for that item with "No fees/fines shall be refunded if a lost item is returned more than X <intervals> late" with X blank
        • When that item is returned
        • Then:
          • Charge overdue fee by calling module created by CIRC-524 (this module is also called by the check in process and regular renewals to calculate overdue fines)
      3. Scenario
        • Given an item with the status Declared lost, and a Lost Item Fee Policy for that item with radio button set to "If lost item returned or renewed: Do not charge overdues"
        • When that item is returned
        • Then:
          • Do not charge overdue fine

      CANCEL/REFUND LOST ITEM PROCESSING FEE
      (Note: This processing is the same as CIRC-716, the user story is just written a bit differently).

      • Find existing fee/fine record for item with Fee/Fine Type = "Lost item processing fee", remember there can be multiple fee/fine records for one item (find fee/fine record via the loan record if loan record still exists; if not, use item barcode to find the fee/fine record)
      • If fee/fine record for Fee/fine type is not found
        • Do nothing further with the lost item processing fee
      • Else
        • Continue on
      • If the fee wasn't totally waived, paid, transferred and/or cancelled already (i.e. there is a Remaining amount), you must cancel what is left by creating a fee/fine "action" record for the lost item processing fee that is a CANCELLATION of the remaining lost item processing fee (see attachment FF-Details-Cancellation.jpg)
        • Action in fee/fine detail record will be "Cancelled item returned"
        • Amount in fee/fine detail record will be billed amount minus any waived, paid, transferred and/or cancelled amounts (look for action records with Action starting with "Waive", "Paid", "Transferred" and "Cancel") and subtract that amount from billed amount (see attachment Waive-and-Paid-Example.JPG))
        • Create at in fee/fine detail record will be service point where item was returned
        • Source in fee/fine detail record will be name of staff member logged in
        • PO doesn't want to give details for building the fee/fine "action" record here, in case they conflict with what is actually being done (there are many examples in FOLIO for building the "action" record)
        • Create patron notice for the cancellation, if one is set up
      • If patron has paid part or all of the lost item processing fee, and has not already been given a refund, a partial/full refund must be initiated. The refund to the patron would include the sum of all Amounts for "Paid" Actions (see attachment FF-Details-Refund.jpg).
        • Create a fee/fine Action record for this lost item processing fee that is a CREDIT of the amount the patron has paid on the lost item processing fee
          • Action in fee/fine detail record will be "Credited fully"
          • Amount in fee/fine detail record will be "Paid" Action amounts (could be 0 to many) added up (if there are 0, the Action record should NOT be created)
          • Create at in fee/fine detail record will be service point where item was returned
          • Source in fee/fine detail record will be name of staff member logged in
          • Refund reason in fee/fine detail record will be "Lost item found" (Refund reason appears in "Action" column as "Credited fully-Lost item found")
          • Transaction information in fee/fine detail record will be "Refund to patron"
          • PO doesn't want to give details for building the fee/fine "action" record here, in case they conflict with what is actually being done (there are many examples in FOLIO for building the "action" record)
        • Create a fee/fine Action record for this lost item processing fee that is a REFUND of the amount the patron has paid on the lost item processing fee
          • Action in fee/fine detail record will be "Refunded fully"
          • Amount in fee/fine detail record will be "Paid" Action amounts (could be 0 to many) added up (if there are 0, the Action record should NOT be created)
          • Create at in fee/fine detail record will be service point where item was returned
          • Source in fee/fine detail record will be name of staff member logged in
          • Refund reason in fee/fine detail record will be "Lost item found" (Refund reason appears in "Action" column as "Refunded fully-Lost item found")
          • Transaction information in fee/fine detail record will be "Refunded to patron"
          • PO doesn't want to give details for building the fee/fine "action" record here, in case they conflict with what is actually being done (there are many examples in FOLIO for building the "action" record)
        • Create patron notice for the refund to patron, if one is set up
      • If patron has had part or all of the lost item processing fee transferred by the library, and not already had a refund issued for the transfer, a partial/full refund must be initiated. The refund to the patron would include the sum of all Amounts for "Transfer" Actions (see attachment FF-Details-Refund).
        • Create a fee/fine Action record for this lost item processing fee that is a CREDIT of the amount the patron has transferred on the lost item processing fee
          • Action in fee/fine detail record will be "Credited fully"
          • Amount in fee/fine detail record will be "Transfer" Action amounts (could be 0 to many) added up (if there are 0, the Action record should NOT be created)
          • Create at in fee/fine detail record will be service point where item was returned
          • Source in fee/fine detail record will be name of staff member logged in
          • Refund reason in fee/fine detail record will be "Lost item found" (Refund reason appears in "Action" column as "Credited fully-Lost item found")
          • Transaction information in fee/fine detail record will be "Refund to <Transfer account>"
          • PO doesn't want to give details for building the fee/fine "action" record here, in case they conflict with what is actually being done (there are many examples in FOLIO for building the "action" record)
        • Create a fee/fine Action record for this lost item processing fee that is a REFUND of the amount the library has transferred on the lost item processing fee
          • Action in fee/fine detail record will be "Refunded fully"
          • Amount in fee/fine detail record will be "Transfer" Action amounts (could be 0 to many) added up (if there are 0, the Action record should NOT be created)
          • Create at in fee/fine detail record will be service point where item was returned
          • Source in fee/fine detail record will be name of staff member logged in
          • Refund reason in fee/fine detail record will be "Lost item found" (Refund reason appears in "Action" column as "Refunded fully-Lost item found")
          • Transaction information in fee/fine detail record will be "Refund to patron" when Action record is for paid amounts and "Refund to <Transfer account>" when Action record is for transfer amounts
          • PO doesn't want to give details for building the fee/fine "action" record here, in case they conflict with what is actually being done (there are many examples in FOLIO for building the "action" record)
        • Create patron notice for the refund to transfer account, if one is set up

      CANCEL/REFUND LOST ITEM FEE
      (Note: This processing is the same as CIRC-716, the user story is just written a bit differently).

      • Verify that the patron was actually charged a Lost item fee for this item. (If not, there is no need to continue.) For the loaned item, check for an associated fee/fine record with Fee/fine type of = Lost item fee.
      • If fee/fine record for Fee/fine type is not found
        • Do nothing further with the lost item fee
      • Else
        • Continue on
      • If the fee wasn't totally waived, paid, transferred and/or cancelled already (i.e. there is a Remaining amount), you must cancel what is left by creating a fee/fine "action" record for the lost item fee that is a CANCELLATION of the remaining lost item fee (see attachment FF-Details-Cancellation.jpg)
        • Action in fee/fine detail record will be "Cancelled item returned"
        • Amount in fee/fine detail record will be billed amount minus any waived, paid, transferred and/or cancelled amounts (look for action records with Action starting with "Waive", "Paid", "Transferred" and "Cancel") and subtract that amount from billed amount (see attachment Waive-and-Paid-Example.JPG))
        • Create at in fee/fine detail record will be service point where item was returned
        • Source in fee/fine detail record will be name of staff member logged in
        • PO doesn't want to give details for building the fee/fine "action" record here, in case they conflict with what is actually being done (there are many examples in FOLIO for building the "action" record)
        • Create patron notice for the cancellation, if one is set up
      • If patron has paid part or all of the lost item fee, and has not already been given a refund, a partial/full refund must be initiated. The refund to the patron would include the sum of all Amounts for "Paid" Actions (see attachment FF-Details-Refund.jpg).
        • Create a fee/fine Action record for this lost item fee that is a CREDIT of the amount the patron has paid on the lost item fee
          • Action in fee/fine detail record will be "Credited fully"
          • Amount in fee/fine detail record will be "Paid" Action amounts (could be 0 to many) added up (if there are 0, the Action record should NOT be created)
          • Create at in fee/fine detail record will be service point where item was returned
          • Source in fee/fine detail record will be name of staff member logged in
          • Refund reason in fee/fine detail record will be "Lost item found" (Refund reason appears in "Action" column as "Credited fully-Lost item found")
          • Transaction information in fee/fine detail record will be "Refund to patron"
          • PO doesn't want to give details for building the fee/fine "action" record here, in case they conflict with what is actually being done (there are many examples in FOLIO for building the "action" record)
        • Create a fee/fine Action record for this lost item fee that is a REFUND of the amount the patron has paid on the lost item fee
          • Action in fee/fine detail record will be "Refunded fully"
          • Amount in fee/fine detail record will be "Paid" Action amounts (could be 0 to many) added up (if there are 0, the Action record should NOT be created)
          • Create at in fee/fine detail record will be service point where item was returned
          • Source in fee/fine detail record will be name of staff member logged in
          • Refund reason in fee/fine detail record will be "Lost item found" (Refund reason appears in "Action" column as "Refunded fully-Lost item found")
          • Transaction information in fee/fine detail record will be "Refunded to patron"
          • PO doesn't want to give details for building the fee/fine "action" record here, in case they conflict with what is actually being done (there are many examples in FOLIO for building the "action" record)
        • Create patron notice for the refund to patron, if one is set up
      • If patron has had part or all of the lost item fee transferred by the library, and not already had a refund issued for the transfer, a partial/full refund must be initiated. The refund to the patron would include the sum of all Amounts for "Transfer" Actions (see attachment FF-Details-Refund).
        • Create a fee/fine Action record for this lost item fee that is a CREDIT of the amount the patron has transferred on the lost item fee
          • Action in fee/fine detail record will be "Credited fully"
          • Amount in fee/fine detail record will be "Transfer" Action amounts (could be 0 to many) added up (if there are 0, the Action record should NOT be created)
          • Create at in fee/fine detail record will be service point where item was returned
          • Source in fee/fine detail record will be name of staff member logged in
          • Refund reason in fee/fine detail record will be "Lost item found" (Refund reason appears in "Action" column as "Credited fully-Lost item found")
          • Transaction information in fee/fine detail record will be "Refund to <Transfer account>"
          • PO doesn't want to give details for building the fee/fine "action" record here, in case they conflict with what is actually being done (there are many examples in FOLIO for building the "action" record)
        • Create a fee/fine Action record for this lost item fee that is a REFUND of the amount the library has transferred on the lost item fee
          • Action in fee/fine detail record will be "Refunded fully"
          • Amount in fee/fine detail record will be "Transfer" Action amounts (could be 0 to many) added up (if there are 0, the Action record should NOT be created)
          • Create at in fee/fine detail record will be service point where item was returned
          • Source in fee/fine detail record will be name of staff member logged in
          • Refund reason in fee/fine detail record will be "Lost item found" (Refund reason appears in "Action" column as "Refunded fully-Lost item found")
          • Transaction information in fee/fine detail record will be "Refund to patron" when Action record is for paid amounts and "Refund to <Transfer account>" when Action record is for transfer amounts
          • PO doesn't want to give details for building the fee/fine "action" record here, in case they conflict with what is actually being done (there are many examples in FOLIO for building the "action" record)
        • Create patron notice for the refund to transfer account, if one is set up

      TestRail: Results

        Attachments

          1. CIRC-717 Test Plan.xlsx
            24 kB
          2. Circulation-Rule.jpg
            Circulation-Rule.jpg
            34 kB
          3. Declare-item-lost-loan-details-1.jpg
            Declare-item-lost-loan-details-1.jpg
            256 kB
          4. Declare-item-lost-loan-details-2.jpg
            Declare-item-lost-loan-details-2.jpg
            267 kB
          5. FF-Details-Cancellation.jpg
            FF-Details-Cancellation.jpg
            124 kB
          6. FF-Details-Refunds.jpg
            FF-Details-Refunds.jpg
            216 kB
          7. FF-Details-Refunds-Steps.jpg
            FF-Details-Refunds-Steps.jpg
            310 kB
          8. Item-declared-lost-and-lost-fee-transferred.jpg
            Item-declared-lost-and-lost-fee-transferred.jpg
            147 kB
          9. Item-declared-lost-and-lost-fee-transferred2.jpg
            Item-declared-lost-and-lost-fee-transferred2.jpg
            139 kB
          10. Item-declared-lost-checked-in.jpg
            Item-declared-lost-checked-in.jpg
            103 kB
          11. Item-declared-no-refund-to-bursar.jpg
            Item-declared-no-refund-to-bursar.jpg
            140 kB
          12. No-longer-owe-ffs.jpg
            No-longer-owe-ffs.jpg
            180 kB
          13. screenshot-1.png
            screenshot-1.png
            397 kB
          14. screenshot-2.png
            screenshot-2.png
            79 kB

          Issue Links

            blocks

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. UICHKIN-118 Declared lost item: check in (effect on fines/fees)

            • P2 - normal priority level, must be included in the current development cycle
            • Closed
            clones

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. UICHKIN-118 Declared lost item: check in (effect on fines/fees)

            • P2 - normal priority level, must be included in the current development cycle
            • Closed
            defines

            New Feature - New feature requests UXPROD-2246 Loan: Declared Lost - Fee/Fine work for SET COST

            • P1 - highest priority item, drop everything else before this is resolved, reserved for critical bugfixes
            • Closed
            is blocked by

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. CIRC-577 Back end: Declared lost item: check in

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. CIRC-707 BE - Declared lost item: Assign fees when declared lost w/ SET COST

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Task - A task that needs to be done. FOLIO-2526 snapshot-continuous build fails on tenant admin task

            • TBD - To be determined
            • Closed

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. MODFEE-51 BE - Declared lost item: Manual fee setting for ACTUAL COST fee/fine type

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. UICHKIN-114 Declared lost item: check in

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. UIU-1203 Declared lost item: Display fees when declared lost with SET COST

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. UIU-1580 Declared lost item: Assign fees when declared lost with actual cost

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. UIU-1593 Declared lost item: Manual fee setting for ACTUAL COST fee/fine type

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed
            is cloned by

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. CIRC-729 BE - Declared lost item: check in (effect on fines/fees) - SHARED ACTUAL COST

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. CIRC-730 BACKEND - Declared lost/aged to lost item: check in (effect on fines/fees) - ACTUAL COST

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. CIRC-845 Aged to lost: Check in (effect on fees/fines) - SET COST

            • TBD - To be determined
            • Closed
            is duplicated by

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. UICHKIN-118 Declared lost item: check in (effect on fines/fees)

            • P2 - normal priority level, must be included in the current development cycle
            • Closed
            relates to

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. CIRC-729 BE - Declared lost item: check in (effect on fines/fees) - SHARED ACTUAL COST

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. CIRC-730 BACKEND - Declared lost/aged to lost item: check in (effect on fines/fees) - ACTUAL COST

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. CIRC-765 BE: Refund lost item fees for 'Lost and paid' items

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Bug - A problem which impairs or prevents the functions of the product. CIRC-766 Overdue fine is charged when lost item fees are not refunded

            • TBD - To be determined
            • Closed

            Bug - A problem which impairs or prevents the functions of the product. UICHKIN-183 'Fees/fines owed' note shown for declared lost item but no fees assigned

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. UIU-1669 Refresh 'Fine incurred' field when item declared lost

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Bug - A problem which impairs or prevents the functions of the product. CIRC-790 Wrong tense of 'refund' used for 'action' record created on return of Declared Lost item

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed

            Activity

              People

                bohdan-suprun Bohdan Suprun
                ecboettcher Emma Boettcher
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  TestRail: Runs

                    TestRail: Cases