Explanation of point-of-charging, canceled jobs, and automatic refunds
KB Home | Explanation of point-of-charging, canceled jobs, and automatic refunds
Q When does PaperCut charge users for printing? What happens if I delete a job from the queue?
Windows Print Servers:
PaperCut will charge the user the moment the print job completes spooling to the server. This may also correspond to the time the job prints, however if the job is 2nd or later in the queue, then the point-of-charging will be before printing starts while the job is waiting. If the job is subsequently deleted from the queue the job will be refunded according to the following logic:
If the job has not started printing (e.g. was placed 2nd or later in the queue), the full amount of the job will automatically be refunded.
If the job has started printing or is in the process of printing, the job is not refunded, but instead is marked as a candidate for manual refund (e.g. Canceled but not Refunded). The reason for this is security - that is it’s not possible to tell how many pages have actually printed due to buffering in the printer memory and network connection. The safest approach is to manually handle these exceptions using the one-click refund link listed next to the job in the admin interface. (A behind the scenes comment: In the very early days at PaperCut our software would automatically refund, but the kids at one school worked out that if they deliberately stuck a paperclip in the printer at the right moment, they could get a free or discounted job! Hence we now take a more secure play-it-safe approach.)
Linux and Mac Print Servers:
Due to the method of integration with CUPS, the point-of-charging is when the job is positioned number 1 in the queue and is about to print (On the technical level this is because PaperCut hooks in at the CUPS backend layer). If an error occurs prior to printing, or the job is deleted from the queue early, again the job will automatically be refunded.
The Windows method offers the advantage of immediately notifying the user that they have exceeded their quota/credit when the job completes spooling to the print server. Sites with Mac and Linux servers should be aware that users will not receive the “Print Denied” message (generated as a result of no available credit) until the job is ready to print. This will not be a problem on small sites with lightly loaded queues, however, large sites with heavily loaded queues may require some additional user education.
How do I manage user refund requests?
PaperCut comes with a web based refund management feature. This allows end-users to request refunds via a web form. Administrators can then approve, edit or reject a refund using the system. Administrators may also be alerted to pending refunds via email based server notifications. More information on the refund request feature can be found here.
How do I perform a manual refund?
A manual refund can be performed quickly by any nominated administrator. Simply locate the job in the print log (either the global print log under Printers → Print Log or under ‘ ’Printers →[Printer Name] → ‘Recent Jobs), and click on the one-click Refund link next to the appropriate job. The user’s personal account or the shared account will automatically be refunded and the job will be flagged appropriately. Jobs that are terminated before they finish printing will be listed as “Canceled” and this status can help you verify a user’s refund request.
Partial refunds, if applicable, should be handled via the Adjustments & Charges tab on the appropriate account.
If the connection from the Print Provider to the Application Server goes down:
While the PaperCut Server connection is down, no charging will occur. When the connection is reestablished, charging will be dependent on the Failure Mode settings. If the Failure Mode is:
“Allow new print jobs to print but do not log”, then the print jobs will never be logged and therefore nobody will ever be charged for this printing.
“Allow new print jobs to print and log after reconnection”, then the charging will occur after a few minutes after the connection is reestablished. The jobs will be logged as “delay log” and will be charged according to the settings specified in the Failure Mode i.e will be the defaults or set for a nominated user or a nominated shared account.
“Do not allow new print jobs to print but hold and wait for reconnection”, then charging will occur after reconnection using the normal charging settings (however, during this down time no printing will happen which may not be desirable).
More information on the Failure Mode settings can be found here.
This release contains an updated Java version which no longer supports 32-bit workstations. If you have any 32-bit users launching the User Client or Release Station from a network share, see this Knowledge Base article for more information.