The new Italian fiscal law requires all POS applications to communicate with an RT (Registratore Telematico) fiscal device. One of them is the RT Server, a hardware box located in each store: each POS unit communicates with the RT-Server. The RT-Server communicates directly with the Fiscal Agency.
For this project, there are two mandatory modules to install:
And two optional modules (needed if you use the Self Checkout functionality):
RT Server Adapter
NCR RT Server Adapter is a software component that needs to be installed on each POS. It provides functions to manage the RT Server communication and other tools.
RT Adapter Functionalities are listed below:
- RT Adapter manages the communication between the POS application and the RT-Sever
- RT Adapter receives data from the POS and sends it asynchronously to the RT-Server
- RT Adapter receives data from the RT-Server and sends it to the POS
- RT Adapter manage offline situations
- RT Adapter ensures business continuity in case of offline or problems on the * RT-Server
- RT Adapter manages the receipt signature algorithm (online/offline).
In general, the main purpose of this adapter is to isolate the complexity of the asynchronous communication with the RT Server from each POS unit. This adapter retry the communication with the RT-Server in case the RT-Server is offline, and re-align the data with the server in case of errors. Besides this, the adapter is in charge of calculating the hash signature that the POS unit must print on every sales receipt. The communication between Openbravo Web POS and the RT Adapter will be through Web Service Communication, that is the one for non Java POS. Using this channel of communication, the POS communicated to the RT Adapter using a REST architecture that uses JSON to send and receive data.
RT Server project requires the usage of the Openbravo POS Hardware Manager (HM) software. Openbravo POS HM is a tiny web server that runs on a computer to which the peripherals such as fiscal printer or devices, customer display or cash drawer are connected.
This integration includes below listed sample print templates for sales and returns. These templates have been created according to Italian fiscal requirements. These two templates must be configured in the “Organization” window, under section “Web POS Formats”, therefore for the corresponding store:
- “RTServer Print Ticket” template, that needs to be selected in the field “Print Ticket Template”
- “RTServer Print Return” template, that needs to be selected in the field “Return Template”
It is important to remark that end-customer templates can be based on the above ones, and for sure will add more customizations.
RT Server integration project includes a new “Yes/No” parameter located in the Openbravo backoffice “Client” window, named “Use RT Server”, therefore the integration with this RT device can be enabled or not at Client level, that is for the corresponding Company/Entity. This parameter needs to be selected for Italian companies or entities, which require the integration with an RT-Server.
Below listed preferences need to be enabled for any user within the corresponding Openbravo Client:
- Do not allow Sales with return: This preference allows Openbravo to control that POS sales transactions do not include negative or return items/lines.
- Web POS Avoid Blind and Verified Returns Lines in Same Ticket: This preference allows Openbravo to control not to mix “verified” and “blind” return lines within the same return document anyhow.
- Debug mode for request in RTServer: This preference allows Openbravo to show JSON files sent to the RT-Adapter as a pop-up shown just after POS commercial transactions booking. This preference can be used as a tool to debug problems in the functionality
- LOTC Request Lottery Code Information: This last one should be enabled for the entity, starting from January 1st, 2021 as that is the date from when customer lottery code could be included in commercial transactions.
Below listed preferences need to be disabled:
- Enable Reverse Payments: This preference allows to reverse a payment already made and make it once more by using a different payment method. This preference needs to be disabled as this functionality is not allowed in Italy.
The RT Server integration project includes a new parameter located in the Openbravo backoffice Organization window, named RT Server Store ID. This field will allow the user to enter an ID for a given organization/store. This Store ID will be used by the Initialized RT Adapter command. Store ID must be a four digits string.
The RT Server integration project includes a new parameter located in the Openbravo backoffice Channel Touchpoint window, named RT Server Terminal ID. This field will allow the user to enter an ID for a given terminal or till. This terminal or till ID will be used by the Initialized RT Adapter command. Terminal ID must be a four digits string.
It is important to remark that Store and Register/Till Ids (four digits each) enqueued represent the Register uuid, that is the ID used to identify the register (POS unit) on the RT Server. Register uuid must be printed in the tickets. Besides that, below listed new fields have been created to allow the communication between the terminals or tills of a given store and the corresponding RT-Adapter.
- RT Adapter IP
- RT Adapter Port
RT-Server only understand below listed tender grouping:
- (1) Cash,
- (2) EFT (Electronic)
- (3) Not Paid.
Therefore, a new configuration parameter named RT-Server Payment Type has been created in the Payment Method tab of the backoffice window Channel Touchpoint Type. This new parameter allows to configure every payment method as either Cash, Electronic or Not Paid.
The RT Server integration project includes a new parameter located in the Openbravo backoffice Tax Rate window, named VAT Indication Code, therefore it is possible to configure a VAT indication code for each tax rate created in Openbravo.
Besides that a new parameter has been added for those tax rates configured as Tax Exempt, therefore the corresponding VAT Exclusion Code can be selected for each exempt tax rate.
This feature can be defined at touchpoint level, therefore it is possible to configure whether payment rounding needs to be managed or not for each payment method allowed on a channel touchpoint or terminal//till.
To see how to configure, check this documentation Retail:PaymentRounding