|View Issue Details|
|Type||Category||Severity||Reproducibility||Date Submitted||Last Update|
|feature request||[Retail Modules] RT-Printer||major||always||2021-03-29 10:53||2022-01-20 11:21|
|Priority||urgent||Resolution||open||Fixed in Version|
|Status||acknowledged||Fix in branch||Fixed in SCM revision|
|OS||Linux 32 bit||Database||Oracle||Java version||1.6|
|OS Version||Ubuntu 8.04.1||Database version||126.96.36.199.0||Ant version||1.7.0|
|Product Version||SCM revision|
|Review Assigned To|
|Regression introduced in release|
|Regression introduced by commit|
|Triggers an Emergency Pack||No|
0046170: RT Printer v 2.0 - XML 7 changes
|Description||RT Printer v 2.0 - XML 7 changes|
|Steps To Reproduce||n/a|
|Proposed Solution||See Functional Spec:|
RT 2.0 version
1. - Void/Refund management:
The different ways of issuing a return or cancellation commercial document are described below.
Case A): Issue of return / cancellation documents on the same device from which the document was issued:
To proceed with the issue of a return or cancellation document, a search must first be permitted of the reference commercial document in the permanent detail memory of the device, verifying the correspondence with:
- the serial number of the device from which the commercial document was issued;
- the identification of the commercial document (consisting of the progressive closing number followed by the number progressive number of the commercial document).
Depending on the outcome of the research, the following cases are distinguished:
• A.1) If the search has been successful, it must be possible to issue the commercial document: or by return, for an amount equal to or less than the original one, in regards to each rate; or by
cancellation, exclusively for an amount equal to the one of the reference commercial document, for each rate.
• A.2) If the search has been unsuccessful, only if the date of the commercial document of reference is prior to the date of the first commercial document in the detailed memory (case of DGFE replaced), it must be possible to proceed with the issue of a document for cancellation or return in manual mode as described later in Case B).
In Openbravo terms, the scenario A.1 can be done by using the feature "Verified Returns".
Case B): Issue of return documents / cancellation of a reference commercial document issued by another device (or on another DGFE)
If the commercial document has been issued by another device (device serial number - RT or server-RT - different from the serial number printed on the reference commercial document), or stored on a previous EJD (see case A.2), it must be possible proceed with the issue of a document for cancellation or return by manually entering the following information, which will also be reported on the return / cancellation document:
• the device serial number of the reference document;
• the date of the commercial document to which reference is made;
• the identification of the commercial document to which reference is made;
• the VAT rates of the operations subject to return / cancellation;
• the lottery code, if present in the reference commercial document.
In Openbravo terms, the scenario A.2 or B can be done by using the feature "Blind Returns" enhanced as per described below:
While booking a Blind Return, Openbravo will include a pop-up window named "Fiscal Document Reference", where the seller can manually introduce the fiscal information detailed above, before completing the transaction. All this information should be printed in the original receipt.
Case C): This return scenario allow to manage those kind of situations where the end-customer lost the sale ticket but kept the payment receipt.
In such cases, it will possible to book in Openbravo a blind return, but including the fix value "POS" as "device serial number of the reference document", and besides that "the date of the commercial document to which reference is made"; and the "VAT rates of the operations subject to return / cancellation";
2.- New receipt layout - automatically managed by the RT- Printer
A new payment method: "Sconto a pagare" (Payment Discount) needs to be used whenever the payment should not reduce the daily totals (for example, payments as credit?, payment rounding (down) and product gift card payments/usage)
In Openbravo terms:
A new "Fiscal Department" needs to be created so can it be assigned to the corresponding payment method (RT-Printer parameter "TYPE - Payment Type")
(exiting ones: 0=cash,1=check,2=credit or credit card,3=ticket (ticket restaurant).
New ones to be created:
5 = Not Paid (Non riscosso)
6 = Discount on Payment (Sconto a Pagare)
The amounts related to this new fiscal departments (5 and 6) should not participate in the lottery
Fiscal index below needs to be used as for:
Payment Type = 5 Not Paid
00= No payment (shared on Item and service)
01= No payment ITEM (see below point 4)
02= No payment SERVICE (see below point 4)
03= Receipt followed to Invoice (segue Fattura) - The amounts must be net of VAT.
Whenever an invoice (full invoice) is issued at the time of the sale. That invoice, once in the backoffice, will be sent as an XML file (electronically) to the SDI (see issue related).
Payment Type = 6 Discount on Payment
00= Discount on payment (Sconto a pagare generic usage)
01= Discount on payment - Buono Multiuso (just for Product Gift Card)
See scenarios below.
3.- Payment rounding - not need to enable rounding calculation in the RT-Printer, therefore it is managed by Openbravo POS
Parameter "Kind of rounding" = 000 Rounding disable (default)
For the rounding down we need to use the “Sconto a pagare” for the rounded value. For the rounding up just send the cash payment with the correct amount and in both cases at the end of the receipt print the rounding message as requested from Tax Auth "Arrotondamento".
4.- XML 2.0 - Main changes
The sales must be spitted in two main groups:
Sale of item
Sale of Service
Above means that it is required to:
1. Add kind of sale and attribute to the "Department":
*Sales of goods (SALES_TYPE = 0)
*Sales of service (SALES_TYPE = 1)
through the "Item Type" parameter of each Product.
2. Add new commands to manage acconto, omaggio or buono monouso during the receipt (do we need to cover this functional flows)?
Acconto - down payment (entrega a cuenta) while the item is not delivered, once delivered the 2nd receipt shows that amount in negative (-), and the sale in positive of the product delivered.
DirectIO (1090) type ACCONTO printRecItemAdjustment
Omaggio - Free of charge
DirectIO (1090) type OMAGGIO printRecItemAdjustment
Buono Monouso - Product Gift Card usage can be included as a negative line in the ticket.
DirectIO (1090) type BUONO MONO USO printRecItemAdjustment
In the case of Buono Multiuso - Product Gift Card usage included as a payment method (Sconto a Pagare)
Add the following information 601 Buono Multiuso) printRecTotal. See scenario 4 below.
edited on: 2021-03-30 17:25
Some Functional flows (to be confirmed)
1.- payment not collected for delivered goods (Credit)
Totale complessivo 122.00
di cui iva 22.00
Pagament contante 30.05
Non riscoso (credito) 91.50 (existing payment method 3 - Non Riscoso, this amount does not participate in the lottery)
Sconto a pagare 0.00 (not need to print this)
Impoto pagato 30.50
2.- passive rounding (rounding down 300.02 to 300.00)
totale complesivo 300.02
Di cui iva 47.01
Pagamento Contante 300.00
Sconto a pagare 0.02
Importo pagato 300.00
Add the following information "Discount of Payment with or w/o Buoni Multiuso" to the payment command.
3. Positive Rounding (rounding up from 300.09 to 300.10)
totale complesivo 300.09 (not rounded)
Di cui iva 47.03
Pagamento Contante 300.10
Importo pagato 300.10
4. Sale and usage of a product gift card
Totale complessivo 122.00
di cui iva 22.00
Pagament contante 122.00
Importo pagado 122.00
Totale complessivo 122.00
di cui iva 22.00
Sconto a pagare 122.00
Importo pagado 0.00
|2021-03-29 10:53||psanjuan||New Issue|
|2021-03-29 10:53||psanjuan||Triggers an Emergency Pack||=> No|
|2021-03-29 10:53||psanjuan||Issue generated from||0045875|
|2021-03-29 12:06||psanjuan||Relationship added||related to 0045875|
|2021-03-29 12:06||psanjuan||Assigned To||=> psanjuan|
|2021-03-29 12:06||psanjuan||Status||new => acknowledged|
|2021-03-29 12:06||psanjuan||Summary||RT Printer v 2.0 - Lottery code + XML 2.0 => RT Printer v 2.0 - XML 2.0|
|2021-03-29 12:06||psanjuan||Description Updated||View Revisions|
|2021-03-29 13:05||psanjuan||Summary||RT Printer v 2.0 - XML 2.0 => RT Printer XML 7 (RT 2.0) changes|
|2021-03-29 14:06||psanjuan||Description Updated||View Revisions|
|2021-03-29 14:18||psanjuan||Description Updated||View Revisions|
|2021-03-29 14:35||psanjuan||Description Updated||View Revisions|
|2021-03-29 14:35||psanjuan||Proposed Solution updated|
|2021-03-30 10:05||psanjuan||Proposed Solution updated|
|2021-03-30 10:14||psanjuan||Proposed Solution updated|
|2021-03-30 10:22||psanjuan||Proposed Solution updated|
|2021-03-30 10:51||psanjuan||Proposed Solution updated|
|2021-03-30 13:40||psanjuan||Proposed Solution updated|
|2021-03-30 13:51||psanjuan||Proposed Solution updated|
|2021-03-30 13:57||psanjuan||Proposed Solution updated|
|2021-03-30 14:01||psanjuan||Proposed Solution updated|
|2021-03-30 14:01||psanjuan||Note Added: 0127030|
|2021-03-30 14:11||psanjuan||Proposed Solution updated|
|2021-03-30 14:24||psanjuan||Proposed Solution updated|
|2021-03-30 17:06||psanjuan||Proposed Solution updated|
|2021-03-30 17:11||psanjuan||Proposed Solution updated|
|2021-03-30 17:12||psanjuan||Proposed Solution updated|
|2021-03-30 17:15||psanjuan||Proposed Solution updated|
|2021-03-30 17:25||psanjuan||Note Edited: 0127030||View Revisions|
|2021-03-30 17:27||psanjuan||Proposed Solution updated|
|2021-03-31 10:08||psanjuan||Summary||RT Printer XML 7 (RT 2.0) changes => RT Printer v 2.0 - XML 7 changes|
|2021-03-31 10:08||psanjuan||Description Updated||View Revisions|
|2021-04-06 18:37||psanjuan||Proposed Solution updated|
|2021-04-20 15:57||psanjuan||Proposed Solution updated|
|2021-04-21 11:18||psanjuan||Proposed Solution updated|
|2021-04-21 14:19||psanjuan||Proposed Solution updated|
|2021-05-03 09:42||psanjuan||Proposed Solution updated|
|2021-05-03 09:48||psanjuan||Relationship added||related to 0046453|
|2021-07-13 16:09||rafaroda||Tag Attached: NOR|
|2021-07-13 16:10||rafaroda||Issue Monitored: rafaroda|
|2022-01-20 11:21||psanjuan||Proposed Solution updated|
|Copyright © 2000 - 2009 MantisBT Group|