HealthCheck: Identifying Stuck Credit Reservations

This article outlines the process of identifying reservations that may be stuck and provides guidance on managing such situations.

Applies to YSoft SafeQ 5 and YSoft SafeQ 6.

In a rare situation, it may happen that credit/quota reservations for printing/copying/scanning get stuck or remain pending. This refers to open reservations that haven't been canceled or settled. The following scenario is the most common example:

• User makes a copy on the MFD - YSoft SafeQ creates reservation for it
  • based on terminal type either the part or whole credit may be reserved
• In the middle of copying MFD runs out of paper
• User leaves the MFD without adding more paper and finishing the job > copy job remains active in the MFD and reservation is not settled/canceled in YSoft SafeQ
• The user has no access to the credit/quota that is currently reserved, this may prevent him from making further jobs on other MFD

Resolution:

Resolution

1. Monitor the credit reservations that are stuck for considerably long by the SQL query on the Payment System database (e.g. YPSDB).

   SQL query

   -- Before running the query, un-comment the where condition line based on the version of the SQL server you have, this will exclude reservations from the past 30 minutes to minimize amount of false positive report.
    
   select 'prepaid' as EntitlementType, o.created_date, c.name, c.lookup_key username_payment, c.guid as userID, o.provided_id as reservationID, ae.description, '' as payload from open_transaction o
   left join customer c on c.id = o.customer_id
   left join audit_event ae on ae.transaction_id = o.provided_id
   UNION ALL
   select 'quota' as EntitlementType, qae.created_date, qs.name, qs.name username_payment, (CASE WHEN qae.user_id is NULL THEN qs.guid ELSE qae.user_id END) as userID, qr.reservation_id as reservationID, qae.description, qae.payload from quota_reservation qr
   left join quota_subject qs on qs.guid = qr.quota_subject_guid
   left join quota_audit_event qae on qae.reservation_id = qr.reservation_id
   -- where created_date < (select now() - interval '30' minutes) -- uncomment this on PostgreSQL
   -- where created_date < (select dateadd(mi,-30,GETDATE()))     -- uncomment this on MSSQL
   order by created_date desc

    

   Example of query output
   

   The set of information for each Entitlement Type differs. This is caused by a difference in the implementation of both entitlements. For example:

   • description in quota does not provide the printer name for which the reservation is held because the Payment System actually does not need to know it. The name of printer for troubleshooting purposes has to be acquired based on the numeric prefix in reservationID . The prefix is printer id. For example with 109-c-job-723-20211101 the printer id is 109. This ID can be used in the DB query to obtain the printer name:
     
     • SQDB5 - SELECT name, description, ip_address FROM smartq_devices where id = 109
     • SQDB6 - SELECT name, description, network_address FROM tenant_1.devices where id = 109
   • payload is present only for the quota, is shows information such as number of color pages blocked

   Note that name and username_payment may show the cost center number in case the reservation is based on the shared entitlement, the user who made the operation is represented by userID. The details about particular userID can be obtained this way:

   • SQDB5 - SELECT login, name, surname FROM users where id = 78
   • SQDB6 - SELECT login, name, surname FROM tenant_1.users where id = 78
2. Try to resolve the situation by the standard means:
   1. review the MFD status remotely or locally at MFD where reservation is held (it is visible in description or can be obtained based on id prefix from ReservationID)
   2. cancel the print/copy/scan jobs that are stuck
   3. if the reservation still exists restart the MFD (do this only when canceling jobs did not help)
   4. at this point reservation should disappear itself
   5. instruct user not to leave the MFD without clearing the job from MFD job list at first
      
      • this also helps with prevention of security incidents where job gets released at the point when another user clears the paper jam or adds the paper, some MFD vendors have a setting that job with error is canceled when user logs off
3. If the reservation still stays active at this point:

   1. either cancel the reservation manually (see Working_with_Payment_System)
      note: YSoft SafeQ 6 build 65 or newer is required to see and manage the Quota reservations in the Payment System administrative interface. Reservations for prepaid accounts are visible even in the releases prior this version.

   2. or wait for automated cancellation of a reservation (by default 7 days, setting "Expiration of reservations" in the YSoft Payment System; we strongly recommend to keep the setting at its default value to prevent other unexpected behavior)
4. If you are experiencing frequent situations with reservation being stuck, we also suggest to update MFD firmware to the latest one.