Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    UB:circjob 43 doesn't delete ub_fine_fee if stub no longer exists

    • Article Type: General
    • Product: Voyager
    • Product Version: 7.2.1

    Description:
    Bug Report Form for Issue 16384-13169

    Module(s): Universal Borrowing, Circjob
    Server platform(s) affected: Solaris/all
    PC OS (if applicable): n/a
    Browser & version (if applicable): n/a
    Release(s): reported in 7.2.1; replicated in 7.2.2

    Expected results:
    If a patron has no row for a particular remote db in ub_patron_record and that remote database no longer has a stub corresponding to the home patron (i.e., doesn’t have a row in patron with the home’s db_id and a patron_id_ub value of the home record’s patron_id), circjob 43 should delete any rows for that database in the home patron’s ub_fine_fee table.

    Actual results:
    If a patron has no row for a particular remote db in ub_patron_record and that remote database no longer has a stub corresponding to the home patron, if there are rows in ub_fine_fee for that now nonexistent stub, circjob 43 incorrectly leaves those rows in the database.

    Workflow implications: Reports indicate that patrons have UB fines/fees when they do not; the patrons are also blocked from deletion.

    Replication steps:
    Create a patron in db A.
    Perform a walkup transaction in db B (creating a stub), backdating the due date of the item such that it’s already overdue.
    Discharge the stub record’s charged item, incurring fines on the stub’s patron record.
    To simulate the problem data:
    In db B, manually delete the patron from the patron_address, patron_barcode and patron tables.
    In db A, remove the row referencing this stub in ub_patron_record.
    Run circjob 43 on db A – you’ll see that it does not remove the entries referencing your (now nonexistent) stub’s fine in ub_fine_fee.

    Note: We can’t verify whether the original row in db B’s fine_fee table still exists or now has a fine_fee_balance of 0, because we now have no way to verify what the stub patron’s id was.

    Other information: We cannot replicate any scenario in which a stub can be deleted while it has active fines/fees. This data is potentially caused by a bug that no longer exists, or one that only occurs sporadically.

    Resolution:
    Fixed in Voyager 8.2.2.


    • Article last edited: 10/8/2013