The printer integration inside the application allows you to automatically print documents based on certain events. For example you want to print an invoice document whenever you received an order. The printing job is triggered over the web and sent directly to a printer using different service providers. The printing services that we support and how they can be integrated can be found in the printing documentation sub menu on the left side.
You find more information about printing also in the specific service description.
First of all you have to create a printer configuration. For this go to Space > Connect > Printers and create a configuration. You have to choose a printing services which we support.
|
Note
|
In case you do not see a menu Printer in the application make sure that the feature print is active in your space. |
The first printer configuration that you create is your default printer. Unless specified otherwise the application uses the default printer configuration to print the documents.
You can change the default printers by opening the printer configuration and change the default flag of the printer.
|
Note
|
You can only set one default printer. In case you do forget to set a default printer all your print jobs will fail. |
For certain use cases it can be necessary that you want to print some information or pages from a different tray. For this cases we recommend you to create a new printer configuration that by default prints from another tray. In the use cases where this make sense the application lets you specify different printer configuration for the information that should be printed on another tray.
Printers can be used for different events in the application. It also depends on the features that are active in your space. Below you find a list of possible triggers for a print job.
Print / send the invoice or packing slip to your customer. More information can be found in the Dunning Documentation.
You can define in the connector configuration if and when you want to print / send a reminder to your customer. More information about connectors can be found in the Connector Documentation.
Once the printer is created and configured for the different services it will automatically start to print the document when triggered. Find below more information on how to view and reschedule print jobs.
Print jobs are triggered by certain events in the application that can be configured by you. A list of scheduled and successful print jobs are visible in your account under Space > Connect > Printers > Print Jobs.
In case the printer service is not available we try to send the document regularly to the printer service. During this retry phase the job remains in the
PENDING state. If after a certain number of retries we are not able to reach the service then the job will be moved into the state FAILED.
Failed printing jobs can be rescheduled. To reschedule the job you have to open the print job and press reschedule.
All printed document can be downloaded. For this open the print job and click on download document.
We remove print jobs after awhile to clean up the database. The time we store the print jobs is defined in the Constant
Print Job Retention Time. This can be found in the Documentation under Documentation > API Reference > Types > Constants.
The retention time can not be changed.
The printer integration is as reliable as possible. This means we retry to print the document when the print service is not available. However we are not able to track if a job is actually printed. We rely on the feedback of the service provider. If the provider returns a positive feedback we assume that the job has been printed. In case of a service interruption on our side or on the service provider’s side we track all printed jobs to allow a review of all printed documents.
Our implementation guarantees that a document is only printed when the corresponding database transaction on our side has been committed. This means we only start printing when the data is actually stored in our database and it cannot be reversed anymore. In case of a server failure on our side we retry to print the document until we are sure the document has been printed. However we cannot detect if a document has been already sent to the print service, because the service providers do not allow us to verify that. This means a document may be printed more than once in case of a system failure.
The overall reliability depends also on the printer itself. In case of a power outage the printer may lose all stored print jobs. To establish a reliable end-to-end system eventually a manual check of the printed documents may make sense.