|View Issue Details|
|Type||Category||Severity||Reproducibility||Date Submitted||Last Update|
|feature request||[Retail Modules] RT-Printer||major||always||2021-03-29 10:53||2021-04-06 18:37|
|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||220.127.116.11.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||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):(under research)
2.- New receipt layout (THIS SHOULD BE MANAGED BY THE RT-PRINTER):
2.1 Lottery code for Lottery Receipt or Fiscal ID for Fiscal Document"
(question asked to Epson about those Code/ID, and whether new receipt layout changes are managed by the RT-Printer itself)
2.2 New payment method: "Sconto a pagare" (Payment Discount) 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:
Some new "Fiscal Department" needs to be created so can 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:
4 = Ticket with number ¿?
5 = Not Paid (Non riscosso) ¿?
6 = Discount on Payment (Sconto a Pagare)
The amounts related to this new fiscal department (5 and 6) should not participate in the lottery (to be confirmed by Epson)
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
02= No payment SERVICE
03= Receipt followed to Invoice (segue Fattura)
04= Invoiced (fatture da RT) TBD
Payment Type = 6 Discount on Payment
00= Discount on payment (Sconto a pagare generic)
01= Discount on payment - Buono Multiuso
3.- Paper Saving
Now there are two layouts (layout standard) and (layaout compatto) - How do we need to manage this? can this be configured? - asked to EPSON.
4.- Total Cash amount rounding
It is possible to enable the automatic rounding using the payment cash command.
Rounding settings are:
000 = No rounding
001 = Standard rounding (full rounding)
002 = Always round down
003 = Always round up
5.- 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 "Fiscal Department" parameter of each Tax Rate, related to a product/service tax group)
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.
|Tags||No tags attached.|
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|
|Copyright © 2000 - 2009 MantisBT Group|