Explanation of point-of-charging, canceled jobs, and automatic refunds

KB Home   |   Explanation of point-of-charging, canceled jobs, and automatic refunds

Main.ExplanationOfPointOfCharging History

Hide minor edits - Show changes to output

Changed line 19 from:
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 [[https://www.papercut.com/products/ng/manual/ch-printer-mgmt-refund-print-jobs.html|here]].
to:
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 [[https://www.papercut.com/products/ng/manual/applicationserver/topics/printer-refund-print-jobs.html|here]].
October 09, 2014, at 07:00 AM by 203.222.91.204 -
Changed lines 19-20 from:
PaperCut comes with a web based refund management feature.  This allows end-users to request refunds via a web from.  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 [[https://www.papercut.com/products/ng/manual/ch-printer-mgmt-refund-print-jobs.html|here]].
to:
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 [[https://www.papercut.com/products/ng/manual/ch-printer-mgmt-refund-print-jobs.html|here]].
Changed line 37 from:
[-keywords: refund, refunds, refunding, failed or canceled prints, paper jams, errors, charge time -]
to:
[-keywords: refund, refunds, refunding, failed or canceled prints, paper jams, errors, charge time, point of charging -]
August 25, 2010, at 01:00 AM by Tim - Link back to the manual for more info.
Changed line 27 from:
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:
to:
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:
Added line 31:
More information on the Failure Mode settings can be found [[https://www.papercut.com/products/ng/manual/ch-printer-mgmt-fail-mode.html|here]].
Changed line 26 from:
!!!If the connection from the Print Provider to the Application Server goes down
to:
!!!If the connection from the Print Provider to the Application Server goes down:
August 25, 2010, at 12:47 AM by Tim - Mention charging behavior when Server connection is down
Added lines 26-30:
!!!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).
November 17, 2009, at 10:45 AM by 218.214.136.115 -
Added lines 18-20:
!!!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 from.  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 [[https://www.papercut.com/products/ng/manual/ch-printer-mgmt-refund-print-jobs.html|here]].

July 24, 2009, at 07:55 PM by rick - typos and keyword mispell
Changed lines 6-7 from:
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 form the queue the job will be refunded according to the following logic:
to:
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:
Changed lines 19-20 from:
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 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.
to:
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.
Changed line 28 from:
[-keywords: refund, refunds, refunding, failed or cancelled prints, paper jams, errors, charge time -]
to:
[-keywords: refund, refunds, refunding, failed or canceled prints, paper jams, errors, charge time -]
December 04, 2008, at 07:07 PM by Rick clarified server local install language -
Changed lines 14-15 from:
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 form the queue early, again the job will automatically be refunded.
to:
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.
Changed lines 19-20 from:
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 the user's of printer's ''Recent Jobs'' list), and click on the one-click [@Refund@] link next to the appropriate job.  The user's or the shared account will automatically be refunded and the job flagged appropriately.  Errored or cancelled jobs will be listed as "Cancelled" and this status can help you verify a user's story/request.
to:
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 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.
Changed lines 19-20 from:
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 the user's of printer's ''Recent Jobs'' list), and click on the one-click [@Refund@] link next to the appropriate job.  The user's or the shared account will automatically be refunded and the job flagged appropriately.
to:
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 the user's of printer's ''Recent Jobs'' list), and click on the one-click [@Refund@] link next to the appropriate job.  The user's or the shared account will automatically be refunded and the job flagged appropriately.  Errored or cancelled jobs will be listed as "Cancelled" and this status can help you verify a user's story/request.
Changed lines 1-2 from:
(:title Explanation of point-of-charging and automatic refunds :)
to:
(:title Explanation of point-of-charging, canceled jobs, and automatic refunds :)
Changed line 28 from:
[-keywords: refunds, refunding, failed or cancelled prints, paper jams, errors, charge time -]
to:
[-keywords: refund, refunds, refunding, failed or cancelled prints, paper jams, errors, charge time -]
Changed lines 10-12 from:
# 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 dates 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.) -]

to:
# 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.) -]

Deleted line 22:
[-keywords: refunding, failed or cancelled prints, paper jams, errors -]
Changed lines 27-28 from:
[-keywords: refunds, charge time-]
to:

[-keywords: refunds, refunding, failed or cancelled prints, paper jams, errors, charge time -]
Changed lines 10-12 from:
# 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 dates at PaperCut our software would automatically refund, but the kids at one school worked out that if they deliberately stick 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.) -]

to:
# 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 dates 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.) -]

Changed lines 19-23 from:
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 the user's of printer's ''Recent Jobs'' list, and click on the one-click [@Refund@] link next to the appropriate job.
to:
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 the user's of printer's ''Recent Jobs'' list), and click on the one-click [@Refund@] link next to the appropriate job.  The user's or the shared account will automatically be refunded and the job flagged appropriately.

Partial refunds, if applicable, should be handled via the ''Adjustments & Charges'' tab on the appropriate account.

[-keywords: refunding, failed or cancelled prints, paper jams, errors -]
Added lines 18-19:
!!!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 the user's of printer's ''Recent Jobs'' list, and click on the one-click [@Refund@] link next to the appropriate job.
Changed lines 10-12 from:
# 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 dates at PaperCut our software would automatically refund, but the kids at one school worked out that if they deliberately stick a paperclip in the printer at the right moment, they could get a free or discounted job!  Hence we now take a more secure and play-it-safe approach.) -]

to:
# 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 dates at PaperCut our software would automatically refund, but the kids at one school worked out that if they deliberately stick 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.) -]

Changed lines 10-12 from:
# 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.

to:
# 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 dates at PaperCut our software would automatically refund, but the kids at one school worked out that if they deliberately stick a paperclip in the printer at the right moment, they could get a free or discounted job!  Hence we now take a more secure and play-it-safe approach.) -]

Changed lines 14-15 from:
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, again the job will automatically be refunded.
to:
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 form the queue early, again the job will automatically be refunded.
Changed lines 1-2 from:
(:title Explanation of Point Of Charging :)
to:
(:title Explanation of point-of-charging and automatic refunds :)
Changed lines 10-12 from:
# 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.

to:
# 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.

Changed lines 14-17 from:
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.  If an error occurs prior to printing, again the job will automatically be refunded.

The Windows method of offers the advantage that if
the user exceeds their quota/credit, they will receive immediate notification the moment the job completes spooling.  Site with Mac and Linux servers should be aware that users will not receive the "Print Denied" message due to no available credit until the job is ready to print.  This will not be a problem on small sites with lightly loaded queues, but large some additional user education may be required on large sites with long queues.
to:
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, 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. 
Changed line 5 from:
!!!Windows Servers:
to:
!!!Windows Print Servers:
Changed line 13 from:
!!!Linux and Mac:
to:
!!!Linux and Mac Print Servers:
Changed lines 18-22 from:
'''Catagories''':
to:
----
''Categories:'' [[!Administration]]
----

[-keywords
: refunds, charge time-]
Added lines 1-18:
(:title Explanation of Point Of Charging :)

Q: When does PaperCut charge users for printing?  What happens if I delete a job from the queue?

!!!Windows 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 form 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.


!!!Linux and Mac:
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.  If an error occurs prior to printing, again the job will automatically be refunded.

The Windows method of offers the advantage that if the user exceeds their quota/credit, they will receive immediate notification the moment the job completes spooling.  Site with Mac and Linux servers should be aware that users will not receive the "Print Denied" message due to no available credit until the job is ready to print.  This will not be a problem on small sites with lightly loaded queues, but large some additional user education may be required on large sites with long queues.

'''Catagories''':

Comments

Share your findings and experience with other PaperCut users. Feel free to add comments and suggestions about this Knowledge Base article. Please don't use this for support requests.

Article last modified on May 12, 2016, at 05:50 AM
Printable View   |   Article History   |   Edit Article