Immutable Reports

Contents 1 Introduction 2 Configuration 3 Integrations 4 Backoffice functioning 5 POS functioning 5.1 For developers 6 Performance implications

Introduction

The aim of this project is to implement a feature that allows organizations to work with reports that once generated won’t change again. This means that all the reprints done after the report creation will be exactly as the first one.

Configuration

To activate this feature, you should go to the Organization window and select Enabled in the Reprintable Documents dropdown.

Integrations

This project included both Amazon S3 and Azure Storage implementations. To change the destination of all the future reprintable documents, go to the Attachment Configuration window, add a new record, select the Reprintable Documents option in the Attachment Type drop down and then select the option you prefer in the Attachment Method drop down.

Backoffice functioning

When working with orders or invoices (within the Sales Order, Sales Invoice, Purchase Order or Purchase Invoice windows) related to organizations with the Immutable reports feature active, if the toolbar’s print button is pressed and there is a reprintable document attached, it will be used for reprinting rather than generating a new one (same for the send email button).

Only reprintable documents originally generated as pdf will be reprintable from the backoffice. If the document was initially a thermal document, an error message explaining it can be only reprinted from a POS with a thermal printer will be displayed and nothing will be printed. It has been agreed that reprint from backoffice is not supporting multi-selection for the moment. This implies that if we have at least one record from an organization with the Immutable reports feature not activated within our selection, the print button will appear deactivated. On the other hand, as the send email button doesn’t merge the concerned documents, it will remain activated and fully working in any case.

POS functioning

Currently, it is possible to regenerate a printable document for a closed order, retrieving it online from the server and clicking on the print button/menu item. This flow will be kept from the user point of view. But instead of directly regenerating the document, when the document is going to be reprinted the flow will be as follows: Fetch (online) the reprintable document: If present, it will be sent to be printed. If present in the table but it is not possible to reach the document, an error message will be displayed and the document cannot be reprinted. If not present. A new reprintable document will be generated using the fronted API, printed and persisted for future use. POS2 implements a reprint last document, which takes the source information from a slice of the state (LastOrderComplete) which keeps the last completed ticket. When this button is clicked, the reprinting API will be invoked and the persisted information of the last generated reprintable document will be fetched to generate the printing.

For developers

To use this feature from the POS, the object reprintableDocument should be passed inside the printSettings parameter from the print message. This object accepts a reportName property that may be used to specify a different template when working with duplicates. We also have the boolean parameter IS_DUPLICATE for jrxml templates (isDuplicate fot xml ones) which when true allows the use of a duplicate watermark.

Performance implications

If you want to have a deeper understanding about this, check out the results obtained from the performance tests we have done clicking here.