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

Open
#771 0 comments 0 reactions 0 assignees View on GitHub
market-it scu-it-customrtprinter scu-it-customrtserver scu-it-epsonrtserver
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.