Dieser Artikel beschreibt Besonderheiten, welche im Rahmen der litauischen Fiskalisierung beachtet werden müssen, bzw. welche sich aus den Gesetzen und technischen Anforderungen ergeben. Eine Übersicht der in diesem Artikel verwendeten Begriffen und deren Bedeutung finden Sie im Artikel Begriffe der litauischen Fiskalisierung.

Inhaltsübersicht:

• Voraussetzungen - was wird für den konformen Kassenbetrieb benötigt?
• Sicherheitsmodul - was ist das und welche speziellen Funktionen stehen damit im Zusammenhang?
• iEKA-Kommunikation - was ist dabei zu beachten?
• Spezielle Prozesse - welche Besonderheiten gibt es bei:
  • Retouren/Umtausch
  • Technisches Journal
  • Summenbildungen in Berichten
  • Ein- & Auszahlungen
  • Transaktionsabbruch
  • Verkauf von besonderen Waren
• Berichte - welche Berichte müssen erzeugt werden und welche Daten müssen enthalten sein?
• EKJ - was ist das und was sind die Anforderungen?

Voraussetzungen

Damit eine Registrierkasse in Litauen in Betrieb genommen werden kann, wird folgendes benötigt:

Service Company

Nur Vertreter einer zertifizierten Service Company dürfen Registrierkassen in Betrieb nehmen und diese mit dem iEKA-Service sowie dem Sicherheitsmodul verbinden.

Sie können über die Konfiguration Litauen eine Service Company definieren. Voraussetzung, dass eine Service Company ausgewählt werden kann (als Drop-Down Element in der Konfiguration zur Verfügung steht), ist ein Vertrag zwischen Distributor und Service Company. Nach Hinterlegung/Aktivierung des Vertrages im RetailForce Portal, steht ein Eintrag der Service Company in der Konfiguration zur Verfügung.

Sicherheitsmodul

Jede Registrierkasse muss mit einem zertifizierten Sicherheitsmodul ausgestattet werden. Das Sicherheitsmodul hängt nur bedingt mit der Service Company zusammen. Bitte achten Sie aber bei der Beschaffung eines Sicherheitsmodules darauf, dass dies auch vom RetailForce System unterstützt wird.

Aufgaben des Sicherheitsmodul sind u.a. das Signieren von Transaktionsdaten, die Verwaltung von Summenzählern, sowie die sichere Verwahrung von privaten und öffentlichen Schlüsseln und digitalen Zertifikaten. 

Service Company Parameter

Nachdem eine Service Company in der Konfiguration ausgewählt und die Konfiguration entsprechend einer Entität (Organisation, Company, Store, Terminal) zugewiesen wurde, kann ein Mitarbeiter der Service Company die s.g. Service Company Parameter (siehe Begriffe der litauischen Fiskalisierung), je Terminal, eintragen. 

Wenn die Registrierkasse über ein Sicherheitsmodul verfügt und die Service Company Parameter eingetragen wurden, kann die Kasse (der Client) in Betrieb genommen werden.

Sicherheitsmodul

Daten von Fiskaltransaktionen werden automatisch, vom RetailForce Fiskalisierungs-Service, über das Sicherheitsmodul signiert. 

Die Aktivierung des Sicherheitsmodules erfolgt automatisch, im Zuge der Inbetriebnahme (Initialisierung). Dabei werden auch notwendige digitale Zertifikate in das Sicherheitsmodul geladen.

Digitale Zertifikate

Die Laufzeit von Zertifikaten, welche zur Signierung von Daten und für andere Zwecke verwendet werden, müssen vor Ende der Gültigkeit erneuert werden.

Um Zertifikate zu tauschen, stellt das Fiskalisierungs-Service die Funktion:

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

zur Verfügung. 

Beim Aufruf des Endpunktes, prüft das Fiskalisierungs-Service (Middleware), ob ein Tausch der Zertifikate notwendig ist. Falls sich die Gültigkeit eines Zertifikates seinem Ende nähert, wird eine Tausch des Zertifikates gegen ein Neueres durchgeführt.

Update notwendig

Ein Zertifikatstausch ist nur nach einem Tagesabschluss / Report (Z) (EndOfDay-Dokument) möglich. Bei jedem EndOfDay-Dokument wird in der fiscalResponse die Property "certificatesUpdateRequired" zurückgegeben.

Ist der Wert von "certificatesUpdateRequired" = true, so muss das Vorsystem einen Zertifikatstausch mittels des Endpunktes POST /api/v1/management/lithuania/{clientId}/certificate-update einleiten.

Werte Sicherheitsmodul

Aktuell im Sicherheitsmodul vorhandene Werte (Umsatzzähler, Kassen-ID, Anzahl signierter Dokumente, und andere) können mit Hilfe des Endpunktes

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

ausgelesen werden.

Reset Test-Sicherheitsmodul

Test-Sicherheitsmodule können, im Gegensatz zu Sicherheitsmodule für den Echtbetrieb, auf Werkseinstellungen zurückgesetzt werden. Dies ist gerade in der Implementierungsphase wichtig, wenn etwa Fehler aufgetreten sind (z.B. in der iEKA-Kommunikation - siehe weiter unten).

Ein Reset wird mittels des Endpunktes

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

durchgeführt.

iEKA-Kommunikation

Neben dem Signieren von Transaktionsdaten über das Sicherheitsmodul, ist die Datenübertragung an das Online-System der Finanzverwaltung (iEKA), eine der wesentlichen Anforderungen der litauischen Fiskalisierung.

Das RetailForce System übernimmt die automatische Kommunikation mit iEKA. Dabei schränkt iEKA die Anzahl der Datensätze, welche innerhalb eines bestimmten Zeitraumes, bzw. die Häufigkeit der Übertragung / Abfragen (Requests) innerhalb eines Zeitraumes, ein. Aus diesem Grund übermittelt das Fiskalisierungs-Service Daten nicht in Echtzeit, sondern asynchron an iEKA.

Debugging

Daten, welche als Basis für die Datenübertragung dienen, speichert das Fiskalisierungs-Service im Ordner (z.B. bei Windows-Systemen) C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles ab.

Ablauf

Im oben beschriebenen Ordner sind in der Regel 3 Unterverzeichnisse enthalten:

• send - Daten welche noch nicht an iEKA übertragen wurden
• accepted - Daten welche an iEKA gesendet wurden und vom System grundsätzlich akzeptiert wurden.
• 20xy - Antwort von iEKA nach der Datenvalidierung zu jedem einzelnen Datensatz (steht für das Jahr in dem die Transaktion aufgezeichnet wurde)

Die Datenübermittlung an iEKA durchläuft den folgenden Prozess:

1. RetailForce Client empfängt Daten von Vorsystem ("Registrierkasse") und
2. konvertiert diese in das iEKA-Format als JSON-Datei.
3. Diese JSON-Datei wird im Ordner \\lithuaniaFiscalFiles\send abgelegt.
4. Dateien im Ordner \\send werden periodisch (asynchron) an das iEKA-Service übertragen. Vor der Übermittlung werden die JSON-Dateien in das iEKA XML-Format konvertiert.
5. Sobald die Daten im iEKA-System eingelangt sind, bestätigt iEKA den Empfang.
6. Zu diesem Zeitpunkt werden die Transaktionsdaten vom Ordner \\send in den Ordner \\accepted verschoben, zusammen mit der Empfangsbestätigung von iEKA.
   1. Konnten Daten nicht an iEKA übermittelt werden, bleiben im \\send-Ordner liegen und das Fiskalisierungs-Service versucht die Übertragung zu einem späteren Zeitpunkt.
7. Das iEKA-System führt nun eine Prüfung der übermittelten Daten durch. Der Validierungsstatus muss vom Datenübertragungsmodul (Fiskalisierungs-Service) aktiv abgefragt werden 
8. Diese Abfrage erfolgt ebenfalls periodisch, aufgrund der Kommunikationseinschränkung seitens iEKA (siehe oben).
9. Das Ergebnis der Abfrage des Validierungsstatus wird im Ordner 20xy ausgegeben (Daten werden von \\accepted nach \\20xy verschoben).

Transaktionsstatus

Vorsysteme ("Registrierkassen") können den Status einzelner Transaktionen über die Funktionen:

• GET /api/v1/management/lithuania/{clientId}/check-document-status-by-ieka-document-number/{iekaDocumentNumber} und
• GET /api/v1/management/lithuania/{clientId}/check-document-status-by-document-number/{documentNumber}

abrufen.

Spezielle Prozesse

Retouren / Umtausch

Retouren (z.B. Umtausch von Waren) sind in Litauen s.g. non-fiscal documents, also Nicht-fiskaltransaktionen. Sie werden zwar an das iEKA-System übermittelt, aber nicht über das Sicherheitsmodul signiert. Dies bedeutet auch, dass Retourendokumente nicht die Umsatzzähler des Sicherheitsmoduls beeinflussen.

Damit das RetailForce System Retouren korrekt als solche erkennt, müssen die folgenden Properties gesetzt werden:

• "documentType": 0 / "[0] = Receipt"
• "cancellationDocument": true
• "documentReference" - Referenz auf ein anderes Dokument (ursprüngliches Verkaufsdokument) muss gesetzt sein
• negative Transaktionswerte ("GrossValue", "NetValue", "TaxValue", "Amount")

Technisches Journal

Technische Vorgänge müssen in Litauen aufgezeichnet werden. Dies erfolgt, wie auch in anderen Ländern, über das s.g. Technische Ereignisprotokoll / Technische Journal oder AuditLog.

Insbesondere die folgenden Ereignisse müssen aufgezeichnet werden:

• Kassenladenöffnung (DrawerOpen) - muss von Vorsystem übermittelt werden.
• Belegabbruch (DocumentCancelDocument) - wird automatisch aufgezeichnet.

Details dazu finden Sie im Artikel Technische Ereignisse Litauen.

Summenbildung in Berichten

In Berichten (Bericht (Z) - täglicher Fiskalbericht, Bericht (X) - täglicher Zwischenbericht) müssen bestimmte Summen getrennt ausgewiesen werden. Damit dies gewährleistet werden kann, müssen bestimmte Regel bei der Datenübertragung zwischen Vorsystem ("Registrierkassen") und Fiskalisierungs-Service beachtet werden.

Details dazu finden Sie im Artikel Summenbildung in Berichten Litauen.

Ein- & Auszahlungen

Die litauische Fiskalisierung erfordert, dass der Bargeldbestand der Kasse an iEKA übermittelt wird. Um dies zu gewährleisten müssen Ein- und Auszahlungen (z.B. Wechselgeldeinlage) auch vom Vorsystem an das RetailForce Fiskalisierungs-Service (Middleware), in Form von PayIn- und PayOut-Dokumenten, übermittelt werden ("documentType": 11 / "[11] = PayIn" und "documentType": 10 / "[10] = PayOut" mit "businessTransactionType": "[90] = MoneyTransfer").

Bei PayIns und PayOuts muss folgendes beachten werden:

Beispiele JSON Payloads

PayIn:

(Release: 1.11.4; DOM-Version 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; DOM-Version 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": {}
}

Transaktionsabbruch

Ein Abbruch einer Transaktion, vor ihrer Fertigstellung, muss in Litauen aufgezeichnet werden. Dafür wird der Endpunkt

• POST /api/v1/transactions/cancelDocument

verwendet.

Der übermittelte JSON Payload soll

• sämtliche bis zum Abbruch aufgezeichnete Positionen aber
• ein leeres "Payments"-Objekt enthalten.

Beispiel:

(Release: 1.11.4; DOM-Version 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": {}
}

Daten zu Transaktionsabbrüchen müssen an iEKA übermittelt und auch auf Berichten ausgewiesen werden, (siehe nachfolgendes Kapitel).

Auditlog-Eintrag Transaktionsabbruch

Wird ein Payload an POST /api/v1/transactions/cancelDocument übermittelt, erzeugt das RetailForce Fiskalisierungs-Service automatisch einen Eintrag im technischen Ereignisprotokoll / technischen Journal ("Auditlog") vom Typ:

• DocumentCancelDocument

Der Eintrag enthält die Summe (GrossValue) der einzelnen Positionen des übermittelten Payloads, da diese Information

• an iEKA übermittelt und
• auch am Bericht (Z) sowie
• am Bericht (X) ausgewiesen werden muss.

Die Datenübermittlung an iEKA erfolgt über das EndOfDay-Dokument. Wird ein Tagesabschluss gebucht, werden folgende Werte in der FiscalResponse Litauen zurückgegeben:

• "DayCanceledReceiptsDocumentsQuantity" - Anzahl der Transaktionsabbrüche je Tag
• "DayCanceledReceiptsDocumentsAmount" - (Brutto-) Summe aller Transaktionsabbrüche

Verkauf von besonderen Waren

In Litauen muss der Verkauf bestimmter Waren speziell ausgezeichnet werden. Die Verkäufe werden als eigene Summen an das iEKA System übermittelt, als auch in Berichten (Report (X), Report (Z)) angeführt.

Diese so-genannten "Special Goods Sales" umfasst die Warengruppen:

• Alkohol und
• Treibstoffe

Im RetailForce DOM können betroffene Artikel über die Eigenschaft "itemTypeClassification" entsprechend markiert werden. Welche Artikelgruppen in Litauen als "Special Goods" gelten, kann über die "FiscalCountryProperties" (Eigenschaft: "supportedItemTypeClassification") abgefragt werden.

Berichte

Kassensysteme müssen in der Lage sein, die folgenden Berichte zu erzeugen:

• Bericht (X) - täglicher Zwischenbericht (auch Report (X))
• Bericht (Z) - täglicher Fiskalbericht (auch Report (Z))
• Detaillierter Fiskalbericht
• Zusammenfassender Fiskalbericht

Weitere Informationen, welche Daten in den jeweiligen Berichten enthalten sein müssen, finden Sie im Artikel Beleganforderungen Litauen.

EKJ