Uploaded image for project: 'mod-feesfines'
  1. mod-feesfines
  2. MODFEE-38

Refund fees/fines

    XMLWordPrintable

Details

    • EPAM-Veg Sprint 37, EPAM-Veg Sprint 38, EPAM-Veg Sprint 39
    • 2
    • Vega

    Description

      PURPOSE: To allow library staff to fully or partially refund one or more fees/fines that a patron has paid. Staff member must have refund permission in order to be able to refund fees/fines. Refunds are usually made for closed fees/fines, but may also be open fees/fines that have been partially paid.

      NOTES:

      • For the MVP, the fees/fines refunded to the bursar and the patron will be manually processed. When the refund is processed online it is considered to be completed. The writing of the refund check/transaction to the bursar is assumed to be scheduled. A report of all refunds will be produced (via separate JIRA issue UIU-1164) to assist in the manual processing of refunds.
      • We have working examples of everything described in this user story. Transfer fees/fines (the manual process) is probably the closest example to refunds. We also have a Pay fee/fine and a Waive fee/fine error modal that works like the error modal described in this user story. Please see Holly if you need specific examples to follow.

      OPEN ISSUES:

      1. Need to update PART D, Scenario 1 to include patron notice for refund of automated fees/fines such as Overdue fine, Lost item fee, Lost item processing fee and Replacement processing fee which don't have notice info in the Manual Charges table. We won't be able to do this until one or both of these features are completed-
        • UXPROD-1709 (Send notices for auto-generated fee/fines, overdue)
        • UXPROD-2165 (Send notices for auto-generated fee/fines, aged/lost item)
      2. The Refunds to process manually report still needs to be defined (UIU-1164: Refund fees/fines: Create report of refunds to process manually)

      SCENARIOS:

      ...
      Front-end scenarios
      ...

      When Confirm button pressed

      • Then Create a fees/fines "action" record for each refunded fee/fine. What we call "action" records are what is shown in the table section of the Fee/Fine Details page (see attached mock-up 7-FF-Details-Example.jpg*). PO is not sure of actual field names, but is using Fee/Fine Detail field names instead:
        • Action date should include system date and time of refund (this is what will be used to add this transaction to the report)
        • Action should be set to "Refunded fully" or "Refunded partially", depending on which took place
        • Amount should be set to the amount of this particular fee/fine that was refunded
        • Balance of fee/fine should have refunded amount subtracted from it
        • Transaction information is for payments only and will be blank
        • Created at should be set to service point where the refund was entered
        • Source should identify the library staff member who did the refund
        • Refund reason should be a new data field that will show up on Fee/Fine Details with Action (e.g. Refunded Fully-Lost item found, Refunded Partially-Overpaid)
        • Additional information includes both Additional information for staff and Additional Information for patron
      • Send patron notice if one was generated

      TestRail: Results

        Attachments

          Issue Links

            Activity

              People

                OleksandrVidinieiev Oleksandr Vidinieiev
                hollyolepm Holly Mistlebauer
                Holly Mistlebauer Holly Mistlebauer
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  TestRail: Runs

                    TestRail: Cases