Il presente articolo descrive le caratteristiche specifiche di cui occorre tenere conto nel contesto della fiscalizzazione lituana, ovvero quelle derivanti dalle normative e dai requisiti tecnici. Una panoramica dei termini utilizzati nel presente articolo e del loro significato è disponibile nell’articolo Terminologia della fiscalizzazione lituana.

Panoramica dei contenuti:

• Prerequisiti: cosa è necessario per un funzionamento conforme del registratore di cassa?
• Modulo di sicurezza – che cos’è e quali funzioni specifiche gli sono associate?
• Comunicazione iEKA – quali aspetti occorre considerare?
• Procedure speciali – quali sono le caratteristiche specifiche relative a:
  • Resi/sostituzioni
  • Registro tecnico
  • Totali nei report
  • Depositi e prelievi
  • Annullamento delle transazioni
  • Vendita di merci speciali
• Report: quali report devono essere generati e quali dati devono contenere?
• EKJ – di cosa si tratta e quali sono i requisiti?

Requisiti

Affinché un registratore di cassa possa essere messo in funzione in Lituania, sono richiesti i seguenti requisiti:

Società di assistenza

Solo i rappresentanti di una service company certificata possono mettere in servizio i registratori di cassa e collegarli al servizio iEKA e al modulo di sicurezza.

La service company viene selezionata tramite la configurazione «Lituania». Per poter scegliere una service company (disponibile come voce di menu a tendina nella configurazione) è necessario un contratto tra il distributor e la service company. Una volta che il contratto è stato salvato/attivato nel RetailForce portal, nella configurazione sarà disponibile una voce relativa alla service company.

Modulo di sicurezza

Ogni registratore di cassa deve essere dotato di un modulo di sicurezza certificato. Il modulo di sicurezza è collegato solo in modo indiretto alla service company. Tuttavia, al momento dell’acquisto di un modulo di sicurezza, si prega di assicurarsi che sia supportato anche dal RetailForce system.

Le funzioni del modulo di sicurezza comprendono la firma dei dati delle transazioni, la gestione del contatore del totale generale e l’archiviazione sicura delle chiavi private e pubbliche e dei certificati digitali.

Parametro «Service company»

Una volta selezionata una service company nella configurazione e assegnata a un’entità (organizzazione, azienda, punto vendita, terminal), un tecnico della service company può inserire i parametri della service company (vedere i Termini della fiscalizzazione lituana) per ciascun terminal.

Una volta installato il modulo di sicurezza e configurati i parametri della service company, il registratore di cassa (client) può essere messo in funzione.

Modulo di sicurezza

I dati delle transazioni fiscali vengono automaticamente firmati dal servizio di fiscalizzazione RetailForce tramite il modulo di sicurezza.

Il modulo di sicurezza viene attivato automaticamente durante l’inizializzazione; nel corso di tale processo vengono caricati nel modulo i certificati digitali necessari.

Certificati digitali

I certificati impiegati per la firma dei dati e per altre finalità devono essere rinnovati prima della loro scadenza.

Per il rinnovo dei certificati, il servizio di fiscalizzazione espone il seguente endpoit:

• POST /api/v1/management/lithuania/{clientId}/certificate-update

Quando l’endpoint viene invocato, il servizio di fiscalizzazione (middleware) verifica se i certificati devono essere sostituiti. Se un certificato sta per scadere, viene sostituito con uno più recente.

Aggiornamento necessario

La sostituzione dei certificati è consentita esclusivamente dopo la chiusura giornaliera o il report (Z) (documento EndOfDay). Per ogni documento EndOfDay, la fiscalResponse restituisce la proprietà «certificatesUpdateRequired».

Se il valore di «certificatesUpdateRequired» è «true», il sistema a monte deve avviare una sostituzione del certificato utilizzando l’endpoint POST /api/v1/management/lithuania/{clientId}/certificate-update.

Valori del modulo di sicurezza

I valori memorizzati nel modulo di sicurezza (contatore delle vendite, ID del registratore di cassa, numero di documenti firmati e altri) possono essere letti utilizzando l’endpoint

• GET /api/v1/management/lithuania/{clientId}/param-stick 

Ripristino del modulo di sicurezza di prova

A differenza dei moduli di sicurezza destinati al funzionamento in produzione, i moduli di sicurezza di prova possono essere ripristinati alle impostazioni predefinite di fabbrica. Ciò è particolarmente importante durante la fase di implementazione qualora si siano verificati errori (ad esempio nella comunicazione iEKA – si veda di seguito).

Il ripristino viene eseguito tramite l’endpoint

• DELETE /api/v1/management/lithuania/{clientId}/reset-stick

Comunicazione iEKA 

Oltre alla firma dei dati delle transazioni tramite il modulo di sicurezza, il trasferimento dei dati al sistema online delle autorità fiscali (iEKA) costituisce uno dei requisiti fondamentali della fiscalizzazione lituana.

Il sistema RetailForce gestisce in modo automatico la comunicazione con iEKA. iEKA applica limiti sia al numero di record trasmissibili in un dato intervallo di tempo sia alla frequenza delle richieste. Per questo motivo, il servizio di fiscalizzazione non invia i dati a iEKA in tempo reale, ma in modo asincrono.

Debug

I dati utilizzati come base per la trasmissione vengono memorizzati dal servizio di fiscalizzazione nella directory (ad esempio sui sistemi Windows) C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles.

Procedura

La cartella sopra descritta contiene solitamente tre sottodirectory:

• send - Dati da trasferire a iEKA (dati non ancora trasferiti).
• accepted - Dati inviati a iEKA e accettati dal sistema.
• 20xy - Risposta da parte di iEKA a seguito della convalida dei dati per ogni singolo record (rappresenta l’anno in cui è stata registrata la transazione)

La trasmissione dei dati a iEKA segue il seguente processo:

1. RetailForce Client riceve i dati dal sistema a monte (“registratore di cassa”) e
2. lo converte nel formato iEKA (ma come file JSON).
3. Il file JSON viene archiviato nella cartella di staging \\lithuaniaFiscalFiles\send.
4. I file presenti nella cartella \\send vengono trasferiti periodicamente (in modo asincrono) al servizio iEKA. Prima della trasmissione, i file JSON vengono convertiti nel formato XML di iEKA.
5. Una volta che i dati sono pervenuti al sistema iEKA, quest’ultimo ne conferma la ricezione.
6. A questo punto, i dati delle transazioni vengono spostati dalla cartella \\send alla cartella \\accepted, insieme alla conferma ricevuta da iEKA.
   1. Se il trasferimento a iEKA non va a buon fine, i file rimangono nella cartella \\send e il servizio di fiscalizzazione ritenta il trasferimento in un momento successivo.
7. Il sistema iEKA procede ora alla convalida dei dati trasferiti. Lo stato della convalida deve essere attivamente interrogato dal modulo di trasferimento dati (servizio di fiscalizzazione)
8. Tale richiesta viene inoltre eseguita periodicamente a causa delle restrizioni di comunicazione imposte da iEKA (vedere sopra).
9. Il risultato della richiesta dello stato di convalida viene memorizzato nella cartella 20xy (i dati vengono spostati da \\accepted a \\20xy).

Stato della transazione

I sistemi a monte («registratori di cassa») possono verificare lo stato delle singole transazioni utilizzando le seguenti funzioni:

• GET /api/v1/management/lithuania/{clientId}/check-document-status-by-iEKA-document-number/{iEKADocumentNumber} e
• GET /api/v1/management/lithuania/{clientId}/check-document-status-by-document-number/{DocumentNumber}

Procedure speciali

Resi / sostituzioni di merci

I resi (ad es. la sostituzione di merce) sono considerati in Lituania documenti non fiscali, ovvero transazioni non fiscali. Tali documenti vengono trasmessi al sistema iEKA ma non vengono firmati tramite il modulo di sicurezza. Ciò significa anche che i documenti di reso non incidono sui contatori delle vendite (totale generale) del modulo di sicurezza.

Affinché il sistema RetailForce riconosca correttamente i resi come tali, è necessario impostare le seguenti proprietà:

• "documentType": 0 / "[0] = Scontrino"
• "cancellationDocument": true
• "documentReference": deve essere impostato il riferimento a un altro documento (il documento di vendita originale)
• Valori di transazione negativi (“GrossValue”, “NetValue”, “TaxValue”, “Amount”)

Registro tecnico

In Lituania è necessario registrare i processi tecnici. Come in altri paesi, ciò avviene tramite il Registro degli eventi tecnici / Registro tecnico o AuditLog.

In particolare, devono essere registrati i seguenti eventi:

• Apertura del cassetto portadenaro (DrawerOpen) – deve essere trasmessa dal sistema a monte.
• Annullamento di un documento (DocumentCancelDocument) – viene registrato automaticamente.

Per ulteriori dettagli, si rimanda all’articolo «Eventi tecnici in Lituania».

Totali nei report

Nei report (report (Z) – report fiscale giornaliero, report (X) – report provvisorio giornaliero), determinati totali (generali) devono essere esposti separatamente. A tal fine, è necessario rispettare specifiche regole durante il trasferimento dei dati tra il sistema di origine (“registratori di cassa”) e il servizio di fiscalizzazione.

Per i dettagli, si veda l’articolo «Riepilogo nei report in Lituania».

PayIn e PayOut

La fiscalizzazione lituana richiede che il saldo di cassa nel registratore di cassa (cassetto) venga trasmesso a iEKA. Per garantire ciò, anche le transazioni di versamento e prelievo (ad es. depositi di resto) devono essere trasmesse dal sistema a monte al servizio di fiscalizzazione RetailForce (middleware) sotto forma di documenti PayIn e PayOut (“documentType”: 11 / "[11] = PayIn" e "documentType": 10 / "[10] = PayOut" con "BusinessTransactionType": "[90] = MoneyTransfer").

Per quanto riguarda i PayIn e i PayOut, occorre tenere presente quanto segue:

Esempi di JSON payload

PayIn:

(Release: 1.11.4; Versione DOM 1.6.2)

{
	"ModelVersion": "1.6.2",
	"UniqueClientId": "bef09871-a19b-4eba-9f88-f14e0b482ab3",
	"UniqueCashRegisterId": "0001-0007",
	"FiscalModuleVersion": "1.11.4.593",
	"FiscalCountryModuleVersion": "0.9.7",
	"SoftwareName": "RetailForce NeverPOS",
	"DocumentGuid": "da8e52c6-fb33-4b07-8f9b-7962bc0a0002",
	"DocumentId": "PI001",
	"DocumentNumber": "PI202500001",
	"CreateDate": "2025-12-16T14:43:08.6110527+02:00",
	"BookDate": "2025-12-16T14:43:08.6110527+02:00",
	"DocumentType": 11,
	"User": {
		"Id": "7b1e3d67-25d0-4ad1-a230-5264b3aa1fca"
	},
	"PositionCount": 1,
	"DocumentIssueType": 0,
	"FiscalDocumentNumber": "0",
	"FiscalDocumentStartTime": 0,
	"Positions": [
		{
			"Type": "[3] = Booking",
			"Caption": "Pridėti grynuosius pinigus",
			"BusinessTransactionType": "[11] = PayIn",
			"VatIdentification": 10,
			"VatPercent": 0.0,
			"NetValue": 20.0,
			"GrossValue": 20.0,
			"TaxValue": 0.0,
			"PositionNumber": 0,
			"DeletedPosition": false,
			"AdditionalFields": {},
			"ExternalIdentifier": []
		}
	],
	"Payments": [
		{
			"Amount": 20.0,
			"CurrencyIsoCode": "EUR",
			"UniqueReadablePaymentIdentifier": "CashMovement",
			"AdditionalFields": {},
			"PaymentType": 0,
			"ExternalIdentifier": []
		}
	],
	"AdditionalHeader": [],
	"AdditionalFooter": [],
	"FiscalAdditionalFields": {}
}

PayOut:

(Release: 1.11.4; Versione DOM 1.6.2)

{
	"ModelVersion": "1.6.2",
	"UniqueClientId": "277a1220-5af4-4fc4-900f-694dcc0a6227",
	"UniqueCashRegisterId": "0001-0007",
	"FiscalModuleVersion": "1.11.4.593",
	"FiscalCountryModuleVersion": "0.9.7",
	"SoftwareName": "RetailForce NeverPOS",
	"DocumentGuid": "da8e52c6-fb33-4b07-8f9b-7962bc0a0002",
	"DocumentId": "PO0002",
	"DocumentNumber": "PO202500001",
	"CreateDate": "2025-12-16T12:08:08.6110527+02:00",
	"BookDate": "2025-12-16T12:08:08.6110527+02:00",
	"DocumentType": 10,
	"User": {
		"Id": "7b1e3d67-25d0-4ad1-a230-5264b3aa1fca"
	},
	"PositionCount": 1,
	"DocumentIssueType": 0,
	"FiscalDocumentNumber": "0",
	"FiscalDocumentStartTime": 0,
	"Positions": [
		{
			"Type": "[3] = Booking",
			"Caption": "Grynųjų pinigų išėmimas",
			"BusinessTransactionType": "[10] = PayOut",
			"PayOutType": null,
			"VatIdentification": 10,
			"VatPercent": 0.0,
			"NetValue": -12.0,
			"GrossValue": -12.0,
			"TaxValue": 0.0,
			"PositionNumber": 0,
			"DeletedPosition": false,
			"AdditionalFields": {},
			"ExternalIdentifier": []
		}
	],
	"Payments": [
		{
			"Amount": -12.0,
			"CurrencyIsoCode": "EUR",
			"UniqueReadablePaymentIdentifier": "CashMovement",
			"AdditionalFields": {},
			"PaymentType": 0,
			"ExternalIdentifier": []
		}
	],
	"AdditionalHeader": [],
	"AdditionalFooter": [],
	"FiscalAdditionalFields": {}
}

Interruzione / Abbandono delle transazioni

Qualsiasi interruzione di una transazione prima del suo completamento deve essere registrata in Lituania. L’endpoint

• POST /api/v1/transactions/cancelDocument

viene utilizzato a tale scopo.

Il JSON payload trasmesso deve contenere

• tutte le posizioni registrate fino al momento dell’abbandono, ma
• un oggetto "Payments" vuoto.

Esempio:

(Release: 1.11.4; Versione DOM 1.6.2)

{
	"ModelVersion": "1.6.2",
	"UniqueClientId": "bef09871-a19b-4eba-9f88-f14e0b482ab3",
	"UniqueCashRegisterId": "T001-1502",
	"FiscalModuleVersion": "1.11.4.593",
	"FiscalCountryModuleVersion": "0.9.7",
	"SoftwareName": "x x 1.0",
	"AutomaticVatCalculation": 0,
	"DocumentGuid": "da8e52c6-fb33-4b07-8f9b-7962bc0c0002",
	"DocumentId": "0002",
	"DocumentNumber": "202500001",
	"CreateDate": "2025-12-16T15:19:08.6110527+02:00",
	"BookDate": "2025-12-16T15:19:08.6110527+02:00",
	"DocumentType": 0,
	"User": {
		"Id": "7b1e3d67-25d0-4ad1-a230-5264b3aa1fca"
	},
	"PositionCount": 2,
	"DocumentIssueType": 0,
	"FiscalDocumentNumber": "0",
	"FiscalDocumentStartTime": 0,
	"Positions": [
		{
			"ItemCaption": "Testavimo prekė 222",
			"Discounts": [],
			"Type": "[0] = Item",
			"Quantity": 1.0,
			"QuantityUnit": {
				"Id": null
			},
			"ItemId": "8639d547-3db3-4a44-e0c3-08de3c72db58",
			"ItemType": 0,
			"BaseNetValue": 1.77686,
			"BaseGrossValue": 2.15,
			"BaseTaxValue": 0.37314,
			"BaseTaxValue2": null,
			"BusinessTransactionType": "[0] = Revenue",
			"VatIdentification": 1,
			"VatPercent": 21.0,
			"NetValue": 1.78,
			"GrossValue": 2.15,
			"TaxValue": 0.37,
			"ItemTaxType": 0,
			"PositionNumber": 0,
			"DeletedPosition": false,
			"AdditionalFields": {},
			"ExternalIdentifier": []
		},
		{
			"Type": "[10] = Total",
			"Rounding": 0.0,
			"BaseValue": 2.15,
			"Value": 2.15,
			"Discounts": [],
			"PositionNumber": 1,
			"DeletedPosition": false,
			"AdditionalFields": {},
			"ExternalIdentifier": []
		}
	],
	"Payments": [],
	"AdditionalHeader": [],
	"AdditionalFooter": [],
	"FiscalAdditionalFields": {}
}

I dati relativi all’abbandono della transazione devono essere inviati a iEKA e riportati anche nei report (si veda il capitolo seguente).

Voce nel registro di audit relativa all’interruzione/all’abbandono delle transazioni

Se viene inviato un payload all’endpoint POST /api/v1/transactions/cancelDocument, il servizio di fiscalizzazione di RetailForce genera automaticamente una voce nel registro degli eventi tecnici / giornale tecnico (“registro di audit”) del tipo:

• DocumentCancelDocument

La voce contiene il totale (GrossValue) delle singole voci presenti nel payload trasmesso, poiché tale informazione

• deve essere trasmessa a iEKA e
• deve essere riportata anche nel report (Z) e
• nel report (X).

I dati vengono trasmessi a iEKA tramite il documento EndOfDay. Al momento della registrazione della chiusura giornaliera, nella fiscalResponse Lituania vengono restituiti i seguenti valori:

• "DayCanceledReceiptsDocumentsQuantity" – numero di transazioni interrotte/abbandonate nella giornata
• "DayCanceledReceiptsDocumentsAmount" – importo (lordo) totale di tutte le transazioni annullate o abbandonate

Vendita di beni speciali

In Lituania, la vendita di determinati beni deve essere specificatamente contrassegnata. Tali vendite vengono segnalate al sistema iEKA come totali separati e sono incluse anche nei report (Report (X), Report (Z)).

Queste cosiddette «Vendite di beni speciali» comprendono i seguenti gruppi di prodotti:

• Alcolici e
• Carburante

In RetailForce DOM, le voci pertinenti possono essere contrassegnate di conseguenza utilizzando la proprietà «ItemTypeClassification». I gruppi di prodotti classificati come «beni speciali» in Lituania possono essere interrogati tramite le «fiscalCountryProperties» (proprietà: «supportedItemTypeClassification»).

Report

I sistemi di cassa devono essere in grado di generare i seguenti report:

• Rapporto (X) – rapporto giornaliero provvisorio (noto anche come Rapporto (X))
• Rapporto (Z) – rapporto fiscale giornaliero (noto anche come Rapporto (Z))
• Rapporto fiscale dettagliato
• Rapporto fiscale sintetico

Per ulteriori dettagli sui campi da includere nei rispettivi report, si prega di consultare l’articolo «Requisiti documentali in Lituania».

EKJ

Questo articolo è stato tradotto automaticamente.