Denne artikel beskriver særlige forhold, der skal tages højde for i forbindelse med litauisk fiskalisering, eller som følger af lovgivningen og de tekniske krav. En oversigt over de begreber, der anvendes i denne artikel, og deres betydning findes i artiklen Begreber inden for litauisk fiskalisering.

Indholdsfortegnelse:

• Forudsætninger – hvad kræves der for at drive et kasseapparat i overensstemmelse med lovgivningen?
• Sikkerhedsmodul – hvad er det, og hvilke særlige funktioner er der forbundet med det?
• iEKA-kommunikation – hvad skal der tages højde for?
• Særlige processer – hvad er de særlige forhold ved:
  • Returvarer/ombytninger
  • Teknisk journal
  • Totalsummer i rapporter
  • Indskud og udbetalinger
  • Annullering af transaktioner
  • Salg af specialvarer
• Rapporter – hvilke rapporter skal udarbejdes, og hvilke data skal de indeholde?
• EKJ – hvad er det, og hvordan kan det hentes?

Forudsætninger

For at et kasseapparat kan tages i brug i Litauen, kræves følgende:

Service company

Kun repræsentanter for en certificeret service company må idriftsætte kasseapparater og tilslutte dem til iEKA-tjenesten og sikkerhedsmodulet.

Du kan definere en service company via konfigurationen for Litauen. Der kræves en kontrakt mellem distributøren og service companyen for at kunne vælge en service company (tilgængeligt som et drop-down-element i konfigurationen). Når kontrakten er gemt/aktiveret i RetailForce portalen, vises en post for service companyen i konfigurationen.

Sikkerhedsmodul

For den her beskrevne fiskaliseringsmodel med sikkerhedsmodul skal et kasseapparat være udstyret med et sikkerhedsmodul, der opfylder de gældende litauiske krav. Litauiske regler tillader også kasseapparater med virtuel fiskalisering, som ikke kræver et sikkerhedsmodul (officiel vejledning fra VMI). Sikkerhedsmodulet har kun en løs tilknytning til service companyen. Når du køber et sikkerhedsmodul, skal du dog sikre dig, at det også understøttes af RetailForce systemet.

Sikkerhedsmodulets opgaver omfatter signering af transaktionsdata, styring af totalstælleren samt sikker opbevaring af private og offentlige nøgler og digitale certifikater.

Parameter for service company

Når en service company er valgt i konfigurationen og tildelt en enhed (organisation, virksomhed, butik, terminal), kan en medarbejder hos service companyen indtaste service company-parametrene (se vilkårene for litauisk fiskalisering) for hver terminal.

Hvis kasseapparatet har et sikkerhedsmodul, og service companyens parametre er indtastet, kan kasseapparatet (clienten) tages i brug.

Sikkerhedsmodul

Data fra skattepligtige transaktioner underskrives automatisk af RetailForce-fiskaliseringstjenesten via sikkerhedsmodulet.

Sikkerhedsmodulet aktiveres automatisk under initialiseringen. De nødvendige digitale certifikater indlæses også i sikkerhedsmodulet under denne proces.

Digitale certifikater

Certifikater, der bruges til signering af data og andre formål, skal fornyes, inden de udløber.

Til udskiftning af certifikater stiller fiscalisationstjenesten følgende funktion til rådighed:

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

Når endpointet kaldes, kontrollerer fiscalisationstjenesten (middleware), om certifikaterne skal udskiftes. Hvis et certifikat nærmer sig udløbet af sin gyldighedsperiode, erstattes det med et nyere.

Opdatering nødvendig

En certifikatudskiftning er kun mulig efter en daglig afslutning/rapport (Z) (EndOfDay-dokument). For hvert EndOfDay-dokument returneres egenskaben "certificatesUpdateRequired" i fiscalResponse.

Hvis værdien af "certificatesUpdateRequired" = true, skal det opstrøms system igangsætte en certifikatudskiftning ved hjælp af endpointet POST /api/v1/management/lithuania/{clientId}/certificate-update.

Værdier i sikkerhedsmodulet

Værdier, der er gemt i sikkerhedsmodulet (salgstæller, kasseapparat-ID, antal underskrevne dokumenter m.m.), kan læses ved hjælp af endpointet

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

Nulstilling af test-sikkerhedsmodulet

I modsætning til sikkerhedsmoduler til live-drift kan test-sikkerhedsmoduler nulstilles til fabriksindstillingerne. Dette er især vigtigt i implementeringsfasen, hvis der er opstået fejl (f.eks. i iEKA-kommunikationen – se nedenfor).

En nulstilling udføres ved hjælp af følgende endpoint

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

iEKA-kommunikation

Ud over signering af transaktionsdata via sikkerhedsmodulet er dataoverførsel til skattemyndighedernes onlinesystem (iEKA) et af de centrale krav i den litauiske fiskalisering.

RetailForce systemet håndterer den automatiske kommunikation med iEKA. iEKA begrænser antallet af dataposter, der kan overføres inden for et bestemt tidsrum, samt hyppigheden af overførsler/anmodninger inden for et tidsrum. Af denne grund overfører fiskaliseringstjenesten ikke data til iEKA i realtid, men derimod asynkront.

Fejlfinding

Data, der anvendes som grundlag for dataoverførslen, gemmes af fiskaliseringstjenesten i mappen (f.eks. på Windows-systemer) C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles.

Process

Den ovenfor beskrevne mappe indeholder normalt tre undermapper:

• send – Data, der skal overføres til iEKA (data, der endnu ikke er overført).
• accepted – Data, der er sendt til iEKA og er blevet accepteret af systemet.
• 20xy – Svar fra iEKA efter datavalidering for hver enkelt datapost (angiver det år, hvor transaktionen blev registreret)

Dataoverførslen til iEKA foregår efter følgende proces:

1. RetailForce Client modtager data fra det opstrøms system ("kasseapparatet") og
2. konverterer dem til iEKA-formatet (men som en JSON-fil).
3. Denne JSON-fil gemmes i mappen \\lithuaniaFiscalFiles\send.
4. Filer i mappen \\send overføres med jævne mellemrum (asynkront) til iEKA-tjenesten. Før overførslen konverteres JSON-filerne til iEKA XML-format.
5. Når dataene er ankommet til iEKA-systemet, bekræfter iEKA modtagelsen.
6. På dette tidspunkt flyttes transaktionsdataene fra mappen \\send til mappen \\accepted sammen med den bekræftelse, der er modtaget fra iEKA.
   1. Hvis dataene ikke kunne overføres til iEKA, forbliver de i mappen \\send, og fiscalisationstjenesten forsøger at overføre dem på et senere tidspunkt.
7. iEKA-systemet validerer nu de overførte data. Valideringsstatus skal aktivt forespørges af dataoverførselsmodulet (fiskaliseringstjenesten)
8. Denne forespørgsel udføres også med jævne mellemrum på grund af kommunikationsbegrænsninger fra iEKA's side (se ovenfor).
9. Resultatet af forespørgslen om valideringsstatus gemmes i mappen 20xy (data flyttes fra \\accepted til \\20xy).

Transaktionsstatus

Overstrømssystemer („kasseapparater“) kan kontrollere status for individuelle transaktioner ved hjælp af følgende funktioner:

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

Særlige processer

Returnering/ombytning af varer

Returneringer (f.eks. ombytning af varer) betragtes i Litauen som ikke-fiskale dokumenter, dvs. ikke-fiskale transaktioner. De overføres til iEKA-systemet, men underskrives ikke via sikkerhedsmodulet. Dette betyder også, at returneringsdokumenter ikke påvirker sikkerhedsmodulets salgstællere (samlet total).

For at RetailForce systemet korrekt kan genkende returneringer som sådan, skal følgende egenskaber indstilles:

• "documentType": 0 / "[0] = Kvittering"
• "cancellationDocument": true
• "documentReference" – der skal angives en henvisning til et andet dokument (det oprindelige salgsdokument)
• Negative transaktionsværdier ("GrossValue", "NetValue", "TaxValue", "Amount")

Teknisk journal

Tekniske processer skal registreres i Litauen. Som i andre lande sker dette ved hjælp af den tekniske hændelseslog / det tekniske journal eller AuditLog.

Især følgende begivenheder skal registreres:

• Åbning af kasse (DrawerOpen) – skal overføres af det opstrøms system.
• Annullering af dokument (DocumentCancelDocument) – registreres automatisk.

Se artiklen Tekniske hændelser i Litauen for yderligere oplysninger.

Totalsummer i rapporter

I rapporter (rapport (Z) – daglig skatterapport, rapport (X) – daglig mellemrapport) skal visse (samlede) totaler vises separat. For at sikre dette skal visse regler overholdes ved overførsel af data mellem kildesystemet ("kasseapparater") og skatterapporteringstjenesten.

Se artiklen Summation i rapporter – Litauen for yderligere oplysninger.

PayIn og udbetaling

Den litauiske fiskalisering kræver, at kontantsaldoen i kasseapparatet (kasseskuffen) overføres til iEKA. For at sikre dette skal indbetalings- og udbetalingstransaktioner (f.eks. indbetaling af byttepenge) også overføres fra det opstrøms system til RetailForce-fiskaliseringsservicen (middleware) i form af PayIn- og PayOut-dokumenter ("documentType": 11 / "[11] = PayIn" og "documentType": 10 / "[10] = PayOut" med "BusinessTransactionType": "[90] = MoneyTransfer").

Følgende skal bemærkes vedrørende PayIns og PayOuts:

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

Afbrydelse/ophævelse af transaktioner

Enhver afbrydelse af en transaktion inden dens afslutning skal registreres i Litauen. Endpointet

• POST /api/v1/transactions/cancelDocument

bruges til dette formål.

Den overførte JSON-payload skal indeholde

• alle positioner, der er registreret frem til det tidspunkt, hvor transaktionen blev afbrudt, men
• et tomt »Payments«-objekt.

Eksempel:

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

Data om afbrudte transaktioner skal sendes til iEKA og også vises i rapporter (se det følgende kapitel).

Auditlogpost om afbrydelse/afbrydelse af transaktioner

Hvis der sendes en payload til POST /api/v1/transactions/cancelDocument, genererer RetailForce-fiskaliseringsservicen automatisk en post i den tekniske hændelseslog / det tekniske journal ("revisionslog") af typen:

• DocumentCancelDocument

Posten indeholder det samlede beløb (GrossValue) for de enkelte varer i den overførte payload, da denne information

• skal overføres til iEKA og
• også skal indgå i rapporten (Z) og
• rapporten (X).

Dataene overføres til iEKA via EndOfDay-dokumentet. Når der bogføres en daglig afslutning, returneres følgende værdier i fiscalResponse Litauen:

• "DayCanceledReceiptsDocumentsQuantity" – antal afbrudte/annullerede transaktioner pr. dag
• "DayCanceledReceiptsDocumentsAmount" – (brutto) samlet beløb for alle afbrudte/annullerede transaktioner

Salg af særlige varer

I Litauen skal salget af visse varer mærkes specifikt. Disse salg indberettes til iEKA-systemet som separate totaler og indgår også i rapporterne (Rapport (X), Rapport (Z)).

Dette såkaldte »salg af særlige varer« omfatter følgende produktgrupper:

• Alkohol og
• brændstof

I RetailForce DOM kan de relevante varer mærkes i overensstemmelse hermed ved hjælp af egenskaben "ItemTypeClassification". De produktgrupper, der er klassificeret som "særlige varer" i Litauen, kan søges via "fiscalCountryProperties" (egenskab: "supportedItemTypeClassification").

Rapporter

Kassesystemer skal kunne generere følgende rapporter:

• Rapport (X) – daglig mellemrapport (også kendt som Rapport (X))
• Rapport (Z) – daglig skatterapport (også kendt som Rapport (Z))
• Detaljeret regnskabsrapport
• Sammenfattende regnskabsrapport

For yderligere oplysninger om, hvilke data der skal indgå i de respektive rapporter, henvises til artiklen Dokumentkrav i Litauen.

EKJ

EKJ (elektronisk kontrolbånd, se Vilkår for litauisk fiskalisering) opbevares automatisk af Fiscal Client. I RetailForce Cloud og i API-endepunkterne kaldes det ECJ.

Sådan oprettes EKJ

• Efter hvert dokument, der er signeret af sikkerhedsmodulet (f.eks. kvittering, indbetaling/udbetaling, rapport (X), rapport (Z)), genererer Fiscal Client en tekstversion af dokumentet og tilføjer den til EKJ-filen for den aktuelle dag (én tekstfil pr. dag).
• Hvis klienten er forbundet til RetailForce Cloud, overføres hver post også til cloudarkivet.

Hentning af EKJ

• Fiscal Client: GET /api/v1/management/lithuania/{clientId}/ecj-zip?fromDate={date}&tillDate={date} returnerer en ZIP-fil med én tekstfil pr. dag i den valgte periode. Hvis der ikke findes EKJ-data for perioden, returneres fejlen »Ingen data fundet.«
• RetailForce Cloud Portal: På en litauisk terminal åbner handlingen »Vis ECJ« en dialogboks. Vælg en »Dato« og klik på »Vis« for at få vist den pågældende dags EKJ fra cloud-arkivet.
• RetailForce Cloud API: GET /api/v1.0/implementation/lt/{terminalId}/ecj?date={date} returnerer EKJ for én dag (filnavn og indhold). GET /api/v1.0/implementation/lt/{terminalId}/ecj-zip?fromDate={date}&tillDate={date} starter en eksport af den valgte periode som en ZIP-fil; når eksporten er færdig, kan den downloades via meddelelserne i RetailForce Cloud Portal.

Denne artikel er oversat automatisk.