Denna artikel beskriver särskilda funktioner som måste beaktas i samband med litauisk fiskalisering, eller som följer av lagar och tekniska krav. En översikt över de termer som används i denna artikel och deras betydelser finns i artikeln Termer inom litauisk fiskalisering.

Innehållsöversikt:

• Förutsättningar – vad krävs för att driva ett kassasystem i enlighet med reglerna?
• Säkerhetsmodul – vad är det och vilka särskilda funktioner är kopplade till den?
• iEKA-kommunikation – vad måste man tänka på?
• Särskilda processer – vilka särdrag kännetecknar:
  • Returer/byten
  • Teknisk logg
  • Totalsummor i rapporter
  • Insättningar och uttag
  • Återkallande av transaktioner
  • Försäljning av specialvaror
• Rapporter – vilka rapporter måste genereras och vilka uppgifter måste de innehålla?
• EKJ – vad är det och hur kan man hämta det?

Förutsättningar

För att en kassaapparat ska kunna tas i drift i Litauen krävs följande:

Service company

Endast representanter för en certifierad service company får ta kassaapparater i drift och ansluta dem till iEKA-tjänsten och säkerhetsmodulen.

Du kan ange ett service company via konfigurationen för Litauen. Ett avtal mellan distributören och service company krävs för att ett service company ska kunna väljas (finns som ett alternativ i rullgardinsmenyn i konfigurationen). När avtalet har sparats/aktiverats i RetailForce portal finns en post för service company tillgänglig i konfigurationen.

Säkerhetsmodul

För den här beskrivna modellen för skattehantering med säkerhetsmodul måste ett kassaregister vara utrustat med en säkerhetsmodul som uppfyller gällande litauiska krav. Litauiska regler tillåter även kassaregister med virtuell skattehantering som inte kräver någon säkerhetsmodul (officiell vägledning från VMI). Säkerhetsmodulen har endast en lös koppling till service companyn. När du köper en säkerhetsmodul bör du dock se till att den även stöds av RetailForce systemet.

Säkerhetsmodulens uppgifter omfattar signering av transaktionsdata, hantering av summaräknaren samt säker lagring av privata och offentliga nycklar och digitala certifikat.

Parameter för service company

När en service company har valts i konfigurationen och tilldelats en enhet (organisation, företag, butik, terminal) kan en anställd hos service companyn ange service companyns parametrar (se Villkor för litauisk fiskalisering) för varje terminal.

Om kassaapparaten har en säkerhetsmodul och service companynens parametrar har angetts kan kassaapparaten (clienten) tas i drift.

Säkerhetsmodul

Data från skattepliktiga transaktioner signeras automatiskt av RetailForce-fiskaliserings tjänsten via säkerhetsmodulen.

Säkerhetsmodulen aktiveras automatiskt vid initialiseringen. De nödvändiga digitala certifikaten laddas också in i säkerhetsmodulen under denna process.

Digitala certifikat

Certifikat som används för att signera data och för andra ändamål måste förnyas innan de löper ut.

För att byta certifikat tillhandahåller skatteregistreringstjänsten följande funktion:

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

När slutpunkten anropas kontrollerar fiscalisationstjänsten (middleware) om certifikaten behöver bytas ut. Om ett certifikat närmar sig slutet av sin giltighetstid ersätts det med ett nyare.

Uppdatering krävs

Ett certifikatbyte är endast möjligt efter en daglig avslutning/rapport (Z) (EndOfDay-dokument). För varje EndOfDay-dokument returneras egenskapen ”certificatesUpdateRequired” i fiscalResponse.

Om värdet för ”certificatesUpdateRequired” är true måste det uppströms liggande systemet initiera ett certifikatbyte via slutpunkten POST /api/v1/management/lithuania/{clientId}/certificate-update.

Värden i säkerhetsmodulen

Värden som lagras i säkerhetsmodulen (försäljningsräknare, kassaapparat-ID, antal signerade dokument och andra) kan läsas med hjälp av slutpunkten

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

Återställning av test-säkerhetsmodul

Till skillnad från säkerhetsmoduler för drift kan testsäkerhetsmoduler återställas till fabriksinställningarna. Detta är särskilt viktigt under implementeringsfasen om fel har uppstått (t.ex. i iEKA-kommunikationen – se nedan).

En återställning utförs med hjälp av slutpunkten

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

iEKA-kommunikation

Förutom att signera transaktionsdata via säkerhetsmodulen är dataöverföring till skattemyndigheternas onlinesystem (iEKA) ett av de viktigaste kraven i den litauiska fiskaliseringen.

RetailForce systemet sköter den automatiska kommunikationen med iEKA. iEKA begränsar antalet dataposter som kan överföras inom en viss tidsperiod, liksom frekvensen av överföringar/förfrågningar inom en viss tidsperiod. Av denna anledning överför inte fiscaliserings tjänsten data till iEKA i realtid, utan snarare asynkront.

Felsökning

Data som används som underlag för dataöverföringen lagras av fiscalisationstjänsten i mappen (t.ex. på Windows-system) C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles.

Process

Mappen som beskrivs ovan innehåller vanligtvis tre underkataloger:

• send – Data som ska överföras till iEKA (data som ännu inte har överförts).
• accepted – Data som har skickats till iEKA och godkänts av systemet.
• 20xy – Svar från iEKA efter datavalidering för varje enskild datapost (anger det år då transaktionen registrerades)

Dataöverföringen till iEKA sker enligt följande process:

1. RetailForce Client tar emot data från det uppströms liggande systemet (”kassasystemet”) och
2. konverterar den till iEKA-format (men som en JSON-fil).
3. Denna JSON-fil lagras i mappen \\lithuaniaFiscalFiles\send.
4. Filerna i mappen \\send överförs regelbundet (asynkront) till iEKA-tjänsten. Innan överföringen konverteras JSON-filerna till iEKA:s XML-format.
5. När uppgifterna har anlänt till iEKA-systemet bekräftar iEKA mottagandet.
6. Vid denna tidpunkt flyttas transaktionsdata från mappen \\send till mappen \\accepted, tillsammans med bekräftelsen från iEKA.
   1. Om data inte kunde överföras till iEKA kvarstår de i mappen \\send och fiscalisationstjänsten försöker överföra dem vid ett senare tillfälle.
7. iEKA-systemet validerar nu de överförda uppgifterna. Valideringsstatusen måste aktivt efterfrågas av dataöverföringsmodulen (fiskaliseringsservicen)
8. Denna förfrågan utförs också regelbundet på grund av kommunikationsbegränsningar från iEKA:s sida (se ovan).
9. Resultatet av förfrågan om valideringsstatus lagras i mappen 20xy (data flyttas från \\accepted till \\20xy).

Transaktionsstatus

Uppströmsystem (”kassaregister”) kan kontrollera statusen för enskilda transaktioner med hjälp av följande funktioner:

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

Särskilda processer

Returer/utbyten av varor

Returer (t.ex. byte av varor) betraktas i Litauen som icke-fiskala dokument, dvs. icke-fiskala transaktioner. De överförs till iEKA-systemet men signeras inte via säkerhetsmodulen. Detta innebär också att returdokument inte påverkar säkerhetsmodulens försäljningsräknare (slutbelopp).

För att RetailForce systemet ska kunna identifiera returer korrekt måste följande egenskaper ställas in:

• "documentType": 0 / "[0] = Kvitto"
• "cancellationDocument": true
• "documentReference" – hänvisning till ett annat dokument (det ursprungliga försäljningsdokumentet) måste anges
• Negativa transaktionsvärden ("GrossValue", "NetValue", "TaxValue", "Amount")

Teknisk journal

Tekniska processer måste registreras i Litauen. Precis som i andra länder görs detta med hjälp av den tekniska händelseloggen / den tekniska journalen eller AuditLog.

Följande händelser måste särskilt registreras:

• Öppning av kassalåda (DrawerOpen) – måste överföras av det uppströms liggande systemet.
• Annullering av dokument (DocumentCancelDocument) – registreras automatiskt.

För mer information, se artikeln Tekniska händelser i Litauen.

Totalsummor i rapporter

I rapporter (rapport (Z) – daglig skatterapport, rapport (X) – daglig delrapport) måste vissa (slut)summor visas separat. För att säkerställa detta måste vissa regler följas vid överföring av data mellan källsystemet (”kassaregister”) och skattetjänsten.

För mer information, se artikeln Summering i rapporter Litauen.

PayIn och utbetalningar

Den litauiska skatteregistreringen kräver att kassasaldot i kassan (kassalådan) överförs till iEKA. För att säkerställa detta måste även inbetalnings- och utbetalningstransaktioner (t.ex. inlämning av växel) överföras från uppströmsystemet till RetailForce-skatteregistreringstjänsten (middleware) i form av PayIn- och PayOut-dokument (”documentType”: 11 / "[11] = PayIn" och "documentType": 10 / "[10] = PayOut" med "BusinessTransactionType": "[90] = MoneyTransfer").

Följande måste beaktas för PayIns och PayOuts:

Exempel på JSON payload

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": {}
}

Avbrytande/avbrytande av transaktioner

Varje avbrytande av en transaktion innan den är slutförd måste registreras i Litauen. Endpunkten

• POST /api/v1/transactions/cancelDocument

används för detta ändamål.

Den överförda JSON-payloaden ska innehålla

• alla positioner som registrerats fram till avbrytandet, men
• ett tomt ”Payments”-objekt.

Exempel:

(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": {}
}

Uppgifter om avbrutna transaktioner måste skickas till iEKA och även visas i rapporter (se nästa kapitel).

Revisionsloggpost om avbrytande/avbrytande av transaktioner

Om en payload skickas till POST /api/v1/transactions/cancelDocument genererar RetailForce-fiskaliserings tjänsten automatiskt en post i den tekniska händelseloggen / den tekniska journalen (”revisionslogg”) av typen:

• DocumentCancelDocument

Posten innehåller summan (GrossValue) av de enskilda artiklarna i den överförda payloaden, eftersom denna information

• måste överföras till iEKA och
• även redovisas i rapporten (Z) och
• rapporten (X).

Uppgifterna överförs till iEKA via EndOfDay-dokumentet. När en dagsavslutning bokförs returneras följande värden i fiscalResponse Litauen:

• "DayCanceledReceiptsDocumentsQuantity" – antal avbrutna/ogiltigförklarade transaktioner per dag
• "DayCanceledReceiptsDocumentsAmount" – (brutto) summan av alla avbrutna/ogiltigförklarade transaktioner

Försäljning av särskilda varor

I Litauen måste försäljningen av vissa varor märkas särskilt. Dessa försäljningar rapporteras till iEKA-systemet som separata totalbelopp och ingår även i rapporterna (rapport (X), rapport (Z)).

Dessa så kallade ”försäljningar av särskilda varor” omfattar följande produktgrupper:

• Alkohol och
• bränsle

I RetailForce DOM kan de relevanta artiklarna märkas på motsvarande sätt med hjälp av egenskapen ”ItemTypeClassification”. De produktgrupper som klassificeras som ”specialvaror” i Litauen kan hämtas via ”fiscalCountryProperties” (egenskap: ”supportedItemTypeClassification”).

Rapporter

Kassasystemen måste kunna generera följande rapporter:

• Rapport (X) – daglig delrapport (även kallad Rapport (X))
• Rapport (Z) – daglig skatterapport (även kallad Rapport (Z))
• Detaljerad skatterapport
• Sammanfattande bokslutsrapport

För mer information om vilka uppgifter som måste ingå i respektive rapport, se artikeln Dokumentkrav Litauen.

EKJ

EKJ (elektroniskt kontrollband, se Villkor för litauisk fiskalisering) sparas automatiskt av Fiscal Client. I RetailForce Cloud och i API-ändpunkterna kallas det ECJ.

Hur EKJ skapas

• Efter varje dokument som signerats av säkerhetsmodulen (t.ex. kvitto, in- och utbetalning, rapport (X), rapport (Z)) genererar Fiscal Client en textversion av dokumentet och lägger till den i EKJ-filen för den aktuella dagen (en textfil per dag).
• Om clienten är ansluten till RetailForce Cloud överförs varje post även till molnarkivet.

Hämta EKJ

• Fiscal Client: GET /api/v1/management/lithuania/{clientId}/ecj-zip?fromDate={date}&tillDate={date} returnerar en ZIP-fil med en textfil per dag för den valda perioden. Om det inte finns några EKJ-data för perioden returneras felmeddelandet ”Inga data hittades.”
• RetailForce Cloud Portal: på en litauisk terminal öppnar åtgärden ”Visa ECJ” en dialogruta. Välj ett ”Datum” och klicka på ”Visa” för att visa EKJ för den dagen från molnarkivet.
• RetailForce Cloud API: GET /api/v1.0/implementation/lt/{terminalId}/ecj?date={date} returnerar EKJ-data för en dag (filnamn och innehåll). GET /api/v1.0/implementation/lt/{terminalId}/ecj-zip?fromDate={date}&tillDate={date} startar en export av den valda perioden som en ZIP-fil; när exporten är klar kan den laddas ner via meddelandena i RetailForce Cloud Portal.

Den här artikeln har översatts automatiskt.