Skip to main content
ExLibris

Knowledge Assistant

BETA
 
  • Subscribe by RSS
  • Back
    Aleph

     

    Ex Libris Knowledge Center
    1. Search site
      Go back to previous article
      1. Sign in
        • Sign in
        • Forgot password
    1. Home
    2. Aleph
    3. Knowledge Articles
    4. p_cash_10 with UPDATE=Y doesn't process all z31's for date range

    p_cash_10 with UPDATE=Y doesn't process all z31's for date range

    1. Last updated
    2. Save as PDF
    3. Share
      1. Share
      2. Tweet
      3. Share
    No headers
    • Article Type: General
    • Product: Aleph
    • Product Version: 18.01

    Description:
    I ran p_cash_10 with the following selections:

    From date: 4/1/2007
    To date: 6/30/2007
    Sublibrary: All
    Patron key type: Banner ID
    Update database: N

    The report included 310 obligations.

    Then I ran the service with the same parameters, except Update database: Y.

    The report included 76 obligations. I checked some of the 76 and the GUI and z31 records looked as I thought they should.

    I ran the service 3 more times reporting an additional 93, 7 and 5 obligations (diminishing returns seem to have set in).

    It seems that running it with a relative date (today - nnn) gives somewhat better results, but the maximum would be today - 999 days and we have cash transactions older than that.

    How can we get all of the obligations during the specified date range to update and be reported?

    Resolution:
    If you are planning to run this on a daily or weekly basis once you get caught up, I propose the following:

    1. Use whichever method (absolute date or relative date) works best. For dates over 999 days in the past, you will need to use absolute date, not relative.

    2. Precede each UPDATE = Y run with an UPDATE = N run, so you know what you are supposed to get.

    3. If the initial UPDATE = Y does not give you complete results, run the job as many times as is necessary with UPDATE = Y to get complete results for that time period.

    [From site:]

    We were able to use the service to extract our fees and fines. We did not extract all of the data at one time, rather we broke it down by years. For some years, all of the records transferred at once. For other years we needed to re-run the service repeatedly. Now that we are running the service on a daily basis it seems to be working fine.

    We did have to make a change to tab100, lost-loan-credit-method. We changed from the default 1 (when a lost book is returned, all cash transactions are credited) to 4 (when a lost book is returned, all cash transactions are waived). The default left the original bill as an open transaction that was picked up by p_cash_10 and transferred to AR.


    • Article last edited: 10/8/2013
    View article in the Exlibris Knowledge Center
    1. Back to top
      • p_cash_10 log has error messages: empty export file - ns
      • p_cir_01: " cannot CREATE UNIQUE INDEX; duplicate keys found"
    • Was this article helpful?

    Recommended articles

    1. Article type
      Topic
      Language
      English
      Product
      Aleph
    2. Tags
      1. 18.01
      2. contype:kba
      3. Prod:Aleph
      4. Type:General
    1. © Copyright 2025 Ex Libris Knowledge Center
    2. Powered by CXone Expert ®
    • Term of Use
    • Privacy Policy
    • Contact Us
    2025 Ex Libris. All rights reserved