0052197: Payment losing risk because RTPrinter inactive period

Description

The RTPrinter is able to get the business date on its side. That's why, if the printer is not used for a given business date (imagine, for example, a Sunday) the day after the printer shows a message in the display "PERIODO INNATIVO. ESEGUIRE CHIUSURA", that means that the user should do a fiscal cashup before starting the business journey.

The problem is that, in case the user does not notice and does a sales transaction, an error message provided by the RTP is appearing in the screen not allowing to complete the transaction.

In case the payment is electronic, we can get a situation in which the transaction has not been completed while the payment has been executed.

Steps To Reproduce

-(The RTP must be not used during some days already to be able to reproduce the issue).
.Check that the display of the RTP is informing "PERIODO INNATIVO. ESEGUIRE CHIUSURA"
-Login a terminal using an RTP.
-Check that you're not forced to do a cashup.
-Do a sales transaction and check that when completing it you get an error coming from the RTP.

Proposed Solution

This request is going to be implemented in the JIRA https://openbravo.atlassian.net/browse/RM-6279 [^]
Before making a payment we always need to check RT-Printer status.
The transaction will be fiscalized if the status of the RT-printer is IN SERVIZIO, for the rest of cases/status, the corresponding messages (like the one shown in this issue) will be shown to the user in a pop-up therefore the seller can take action.

IMO Checking whether the RTPrinter status is ready or not should be executed in the application login to prevent any other operation. This will also be more consistent with the Fiscal API and any other Fiscal integration

Tags

No tags attached.

Attached Files

image-20221205-093652.png [^] (1,128,840 bytes) 2023-04-21 11:15

Relationships [ Relation Graph ] [ Dependency Graph ]

Notes
(0149486) psanjuan (viewer) 2023-05-09 12:52	,

(0152143) adrianromero (viewer) 2023-07-05 14:22	Fixed in NOR repositories

Issue History
Date Modified	Username	Field	Change
2023-04-21 11:15	ucarrion	New Issue
2023-04-21 11:15	ucarrion	Assigned To	=> psanjuan
2023-04-21 11:15	ucarrion	File Added: image-20221205-093652.png
2023-04-21 11:15	ucarrion	OBNetwork customer	=> Gold
2023-05-09 12:52	psanjuan	Note Added: 0149486
2023-05-09 12:52	psanjuan	Proposed Solution updated
2023-05-09 13:03	psanjuan	Proposed Solution updated
2023-05-09 13:19	psanjuan	Assigned To	psanjuan => adrianromero
2023-05-11 14:04	adrianromero	Type	defect => feature request
2023-05-11 14:04	adrianromero	Proposed Solution updated
2023-07-05 12:49	adrianromero	Status	new => scheduled
2023-07-05 12:49	adrianromero	Status	scheduled => resolved
2023-07-05 12:49	adrianromero	Resolution	open => fixed
2023-07-05 12:49	adrianromero	Status	resolved => closed
2023-07-05 14:22	adrianromero	Note Added: 0152143