fiskaltrust / fiskaltrust/middleware
Multi-use voucher redeemed as a negative charge item (0x..48): EpsonRTServer, CustomRTPrinter and CustomRTServer print it as a positive NS line
- Dominant language
- C#
- Stars
- 20
- Forks
- 11
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 13
Description
## Summary
The fiskaltrust API allows a multi-use voucher (buono multiuso) to be redeemed as a **negative charge item** `0x…0048` (type of service 4, VAT nibble 8), next to the pay item `0x06` spelling. On the Italian RT this redemption is a payment-phase "sconto a pagare" (Agenzia delle Entrate `ScontoApagare`; Epson protocol 7.00 §9.13, payment type 6 index 01), not an item line.
PR #769 fixes this for the **Epson RT Printer** (issue #514): the redeem line becomes `printRecTotal paymentType="6" index="1"` in sale, refund and void documents. The three sibling SCUs still handle the same line wrongly, and — unlike the Epson printer, which refused the receipt — they **silently produce a wrong document**.
## Per SCU
| SCU | Today | Effect |
|---|---|---|
| **EpsonRTServer** (`scu-it/src/fiskaltrust.Middleware.SCU.IT.EpsonRTServer/EpsonRTServerMapping.cs`, ~L252) | negative `0x…48` line → `Math.Abs` → **positive** `printRecItem` on NS vat id 11 | document total goes **up** by the voucher amount instead of being settled by it |
| **CustomRTPrinter** (`scu-it/src/fiskaltrust.Middleware.SCU.IT.CustomRTPrinter/CustomRTPrinterSCU.cs`, ~L200) | negative `0x…48` line → `Math.Abs` → **positive** item on department 11 | same wrong sign; additionally `GetPaymentType` maps pay item `0x06` to **cash** (1) instead of a voucher payment |
| **CustomRTServer** (`scu-it/src/fiskaltrust.Middleware.SCU.IT.CustomRTServer/CustomRTServerMapping.cs`) | no `0x…48` rule at all: VENDITA line with a **negative amount** and empty vatcode | undefined behaviour on the server side; pay item `0x06` → `SCONTO_A_PAGARE` is already right |
## Expected
Same behaviour as PR #769: a `0x…48` line with a negative amount on a sale (positive on a refund/void, which mirror the sale) is a "sconto a pagare" payment for `|Amount|`, emitted before the other payments, and never an item line. The shared predicate `ReceiptCaseHelper.IsMultiUseVoucherRedeem(chargeItem, request)` (Abstraction) is available for all three.
## References
- #514 (Epson RT Printer report), #769 (fix, with the hardware validation table)
- Epson protocol 7.00 §9.13; AdE `Allegato-SSW-DocumentoCommerciale` 3.7.2 (`ScontoApagare`)
- Reference table: type of service 4 = voucher, V=8 multi-use, "voucher redeem is a negative amount"
Contributor guide
Research direction
Start with PR #769 and the shared ReceiptCaseHelper.IsMultiUseVoucher predicate, then read the mappings in EpsonRTServerMapping.cs, CustomRTPrinterSCU.cs, and CustomRTServerMapping.cs at the referenced areas. Compare sale, refund, and void handling, including payment ordering and the existing 0x06 mapping. Done means 0x…48 is emitted as a sconto a pagare payment rather than an item line in all three SCUs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- backend, payments
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 68/100