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

    p_cir_32 scrubbing z31 in 3 days versus the 30 specified

    • Article Type: General
    • Product: Aleph
    • Product Version: 16.02

    Our library reported the following problem:

    Random vanishing records from cash. Cash histories appear to be disappearing for no reason. Our patron, ABC000002035, paid for two lost items on 2/29/08. One of them shows up in said patron's cash history, one does not. Neither of them should have been scrubbed yet as the requisite number of days have not elapsed, and they would both evaporate at the same time, regardless.

    Our investigation showed the following:

    Ran Cash-03 for 2/29/08 to see if the transactions could be isolated. For the date of 2/29/08, it showed 2 transactions at 11:13 am on receipt number 1469. The patron ID on the first was ABC000002035 (item barcode was 33105005858319) and the second was SCR20080303 (item barcode 33105005857873).

    Can you look and explain why it scrubbed one of the two transactions early, and if we should make alterations to the cir32 parameters to make sure we retain 30 days of information?

    Though the z31_payment_date_key of this z31 which was scrubbed early was 20080229, p_cir_32 compares the calculated scrub-end-date to the z31_date_x (the z31 creation date) *not* the z31_payment_date_key.

    In this case, the z31_date_x was 20080130, which *is* more than 30 days earlier.

    As to why the other z31 transaction for this same patron -- which has an even earlier creation date (20071217) -- was *not* scrubbed.... It seems that the "last-scrubbed-date" which the job calculated was *after* the z31_date_x (20071217) for this transaction. See KB 8192-10231 for a discussion of this anomaly.

    It is using the z31 creation date for the comparisons, but a z31 could sit for a year unpaid. Meanwhile other z31s with more recent creation dates could be scrubbed and result in a recent "last scrubbed date" which causes the older, more-recently-paid z31's to not be scrubbed.

    We are asking that this situation be corrected, but, in the meantime, you would need to use the SQL described in KB 8192-10231.

    • Article last edited: 10/8/2013