Tento článek popisuje zvláštní rysy, které je třeba zohlednit v souvislosti s litevskou fiskalizací nebo které vyplývají z právních předpisů a technických požadavků. Přehled pojmů použitých v tomto článku a jejich významů naleznete v článku Pojmy litevské fiskalizace.

Přehled obsahu:

Předpoklady – co je nutné pro provoz pokladny v souladu s předpisy?
Bezpečnostní modul – co to je a jaké speciální funkce s ním souvisejí?
Komunikace iEKA – co je třeba zohlednit?
Zvláštní procesy – jaké jsou zvláštní rysy:
- Vrácení zboží/výměna
- Technický deník
- Součty ve výkazech
- Vklady a výběry
- Zrušení transakce
- Prodej speciálního zboží
Zprávy – které zprávy je třeba vygenerovat a jaké údaje musí obsahovat?
EKJ – co to je a jaké jsou požadavky?

Předpoklady

Aby bylo možné uvést pokladnu do provozu v Litvě, je nutné splnit následující podmínky:

Servisní společnost

Pokladny mohou uvádět do provozu a připojovat je ke službě iEKA a bezpečnostnímu modulu pouze zástupci certifikované servisní společnosti.

Servisní společnost lze definovat v konfiguraci pro Litvu. K výběru servisní společnosti (dostupné jako položka v rozevíracím seznamu v konfiguraci) je nutná smlouva mezi distributorem a servisní společností. Jakmile je smlouva uložena/aktivována v portálu RetailForce, je v konfiguraci k dispozici záznam o servisní společnosti.

Bezpečnostní modul

Každá pokladna musí být vybavena certifikovaným bezpečnostním modulem. Bezpečnostní modul má se servisní společností pouze volnou souvislost. Při nákupu bezpečnostního modulu se však ujistěte, že je podporován také systémem RetailForce.

Mezi úkoly bezpečnostního modulu patří podepisování transakčních dat, správa počítadla celkových součtů a bezpečné ukládání soukromých a veřejných klíčů a digitálních certifikátů.

Upozornění: Poruchy pokladen (výměna pokladny, výměna hardwaru atd.) vždy vyžadují zakoupení nového bezpečnostního modulu. Další používání bezpečnostního modulu na jiné pokladně/hardwaru není technicky možné.

Parametr servisní společnosti

Jakmile je v konfiguraci vybrána servisní společnost a přiřazena k entitě (organizace, společnost, prodejna, terminál), může zaměstnanec servisní společnosti zadat parametry servisní společnosti (viz Podmínky litevské fiskalizace) pro každý terminál.

Pokud má pokladna bezpečnostní modul a byly zadány parametry servisní společnosti, lze pokladnu (klienta) uvést do provozu.

Poznámka: Rádi vám pomůžeme s kontaktováním litevské servisní společnosti a s pořízením kompatibilního bezpečnostního modulu.

Bezpečnostní modul

Data z fiskálních transakcí jsou automaticky podepisována službou fiskalizace RetailForce prostřednictvím bezpečnostního modulu.

Bezpečnostní modul se aktivuje automaticky během inicializace. Během tohoto procesu se do bezpečnostního modulu načtou také potřebné digitální certifikáty.

Digitální certifikáty

Certifikáty používané k podepisování dat a k dalším účelům je nutné obnovit před uplynutím jejich platnosti.

Pro výměnu certifikátů poskytuje služba fiskalizace následující funkci:

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

Při volání tohoto koncového bodu služba fiskalizace (middleware) zkontroluje, zda je třeba certifikáty vyměnit. Pokud se platnost certifikátu blíží ke konci, je nahrazen novějším.

Aktualizace nutná

Výměna certifikátu je možná pouze po denním uzavření/zprávě (Z) (dokument EndOfDay). Pro každý dokument EndOfDay se v odpovědi fiscalResponse vrací vlastnost „certificatesUpdateRequired“.

Pokud je hodnota „certificatesUpdateRequired“ = true, musí nadřazený systém iniciovat výměnu certifikátu pomocí koncového bodu POST /api/v1/management/lithuania/{clientId}/certificate-update.

Hodnoty bezpečnostního modulu

Hodnoty uložené v bezpečnostním modulu (prodejní pult, ID pokladny, počet podepsaných dokumentů a další) lze načíst pomocí koncového bodu

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

Obnovení testovacího bezpečnostního modulu

Na rozdíl od bezpečnostních modulů pro ostrý provoz lze testovací bezpečnostní moduly resetovat na tovární nastavení. To je obzvláště důležité během implementační fáze, pokud došlo k chybám (např. v komunikaci s iEKA – viz níže).

Reset se provádí pomocí koncového bodu

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

Upozornění: Pokud dojde k resetování bezpečnostního modulu, je nutné v RetailForce Cloud vytvořit nový terminál, resp. inicializovat nového klienta (nezapomeňte zadat parametry poskytovatele služeb!).

Komunikace s iEKA

Kromě podepisování transakčních dat prostřednictvím bezpečnostního modulu je přenos dat do online systému daňových úřadů (iEKA) jedním z klíčových požadavků litevské fiskalizace.

Systém RetailForce zajišťuje automatickou komunikaci s iEKA. iEKA omezuje počet datových záznamů, které lze v určitém časovém období přenést, stejně jako frekvenci přenosů/žádostí v daném časovém období. Z tohoto důvodu služba fiskalizace nepřenáší data do iEKA v reálném čase, ale asynchronně.

Odstraňování chyb

Data sloužící jako podklad pro přenos dat ukládá služba fiskalizace do složky (např. v systémech Windows) C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles.

Proces

Výše popsaná složka obvykle obsahuje tři podsložky:

send – Data určená k přenosu do iEKA (data, která ještě nebyla přenesena).
accepted – data, která byla odeslána do iEKA a byla systémem přijata.
20xy – odpověď od iEKA po ověření dat pro každý jednotlivý datový záznam (představuje rok, ve kterém byla transakce zaznamenána)

Přenos dat do iEKA probíhá následujícím způsobem:

RetailForce Client přijímá data z navazujícího systému („pokladny“) a
převádí je do formátu iEKA (jako soubor JSON).
Tento soubor JSON se ukládá do složky \\lithuaniaFiscalFiles\send.
Soubory ve složce \\send jsou pravidelně (asynchronně) přenášeny do služby iEKA. Před přenosem jsou soubory JSON převedeny do formátu iEKA XML.
Jakmile data dorazí do systému iEKA, iEKA potvrdí jejich přijetí.
V tomto okamžiku jsou transakční data přesunuta ze složky \\send do složky \\accepted společně s potvrzením obdrženým od iEKA.
1. Pokud se data do služby iEKA nepodařilo přenést, zůstanou ve složce \\send a služba fiskalizace se pokusí o jejich přenos později.
Systém iEKA nyní ověřuje přenesená data. Stav ověření musí být aktivně dotazován modulem pro přenos dat (službou pro fiskalizaci).
Tento dotaz se provádí také periodicky z důvodu komunikačních omezení na straně iEKA (viz výše).
Výsledek dotazu na stav ověření se ukládá do složky 20xy (data se přesouvají ze složky \\accepted do složky \\20xy).

Stav transakce

Nadvazující systémy („pokladny“) mohou zkontrolovat stav jednotlivých transakcí pomocí následujících funkcí:

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

Poznámka: Vezměte prosím na vědomí, že z důvodu komunikačních omezení ze strany iEKA může trvat až 10 minut, než bude možné stav konkrétního dokladu dotazovat z pokladny.

Zvláštní postupy

Vrácení / výměna zboží

Vrácení zboží (např. výměna zboží) se v Litvě považuje za nefiskální doklady, tj. nefiskální transakce. Tyto doklady se přenášejí do systému iEKA, ale nejsou podepisovány prostřednictvím bezpečnostního modulu. To také znamená, že doklady o vrácení zboží nemají vliv na počítadla tržeb (celková částka) bezpečnostního modulu.

Aby systém RetailForce správně rozpoznal vrácení zboží jako takové, je třeba nastavit následující vlastnosti:

„documentType“: 0 / „[0] = Účtenka“
„cancellationDocument“: true
„documentReference“ – musí být nastaven odkaz na jiný doklad (původní prodejní doklad)
Záporné hodnoty transakcí („GrossValue“, „NetValue“, „TaxValue“, „Amount“)

Poznámka: Toto označení NENÍ specifické pro Litvu, ale platí ve všech zemích. Prodeje a vrácené zboží v Litvě však musí být vykazovány jako samostatné dokumenty fiskální službě (viz fiscalCountryProperty: „returnAndSaleBehavior“: „multiReceipt“).

Upozornění: V případě vrácení zboží si prosím přečtěte také článek Sčítání v přehledech – Litva!

Technický deník

V Litvě je nutné zaznamenávat technické procesy. Stejně jako v jiných zemích se k tomu používá Technický protokol událostí / Technický deník nebo AuditLog.

Zaznamenávat se musí zejména následující události:

Otevření pokladní zásuvky (DrawerOpen) – musí být přeneseny z předřazeného systému.
Zrušení dokladu (DocumentCancelDocument) – zaznamenává se automaticky.

Další podrobnosti najdete v článku Technické události v Litvě.

Součty ve výkazech

Ve výkazech (výkaz (Z) – denní fiskální výkaz, výkaz (X) – denní průběžný výkaz) musí být určité (celkové) součty uvedeny samostatně. Aby toho bylo dosaženo, je třeba při přenosu dat mezi zdrojovým systémem („pokladnami“) a fiskalizační službou dodržovat určitá pravidla.

Podrobnosti najdete v článku Sčítání v přehledech – Litva.

Vklady a výběry

Litevská fiskalizace vyžaduje, aby byl zůstatek hotovosti v pokladně (pokladní zásuvce) přenesen do systému iEKA. Aby toho bylo dosaženo, musí být transakce vkladů a výběrů (např. vklady drobných) rovněž přenášeny ze zdrojového systému do fiskalizační služby RetailForce (middleware) ve formě dokumentů PayIn a PayOut („documentType“: 11 / „[11] = PayIn“ a „documentType“: 10 / „[10] = PayOut“ s „businessTransactionType“: „[90] = MoneyTransfer“).

U dokumentů PayIn a PayOut je třeba vzít na vědomí následující:

Poznámka: Následující popis procesu zpracování hotovostního zůstatku je dočasným řešením!

documentType

Proces

Hodnoty

11 / „[11] = vklad“

Aktuální zůstatek hotovosti v pokladně musí být odeslán jako první transakce dne.

Zůstatek hotovosti z předchozího dne se po denním uzavření (EndOfDay) NEPŘENÁŠÍ, ale nastaví se na „0“.

Během dne lze provést libovolný počet vkladů. Zůstatek hotovosti se vždy automaticky upraví.

Poznámka: Místo prvního dokladu typu „PayIn“ daného dne můžete samozřejmě odeslat také doklad typu „[90] = OpeningBalance“ s „businessTransactionType“: „[90] = MoneyTransfer“.

Všechny hodnoty („GrossValue“, „Amount“) musí být KLADNÉ.

10 / „[10] = PayOut“

PŘED dokumentem EndOfDay (závěrka dne) musí být celý zůstatek hotovosti nastaven na 0 pomocí PayOut. To je nutné, protože zůstatek se nepřevádí do následujícího dne.

Upozornění: Pokud v tomto okamžiku není uložen žádný PayOut, bude to mít za následek nahlášení nesprávných zůstatků hotovosti do iEKA!

Během dne lze provést libovolný počet výplat. Hotovostní zůstatek se vždy automaticky upraví.

Všechny hodnoty („GrossValue“, „Amount“) musí být ZÁPORNÉ.

Příklady datových náplní JSON

PayIn:

(Verze: 1.11.4; Verze 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:

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

Zrušení / přerušení transakcí

Jakékoli zrušení transakce před jejím dokončením musí být v Litvě zaznamenáno. Koncový bod

POST /api/v1/transactions/cancelDocument

slouží k tomuto účelu.

Přenášená data ve formátu JSON by měla obsahovat

všechny pozice zaznamenané až do okamžiku zrušení, ale
prázdný objekt „Payments“.

Příklad:

(Verze: 1.11.4; verze 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": {}
}

Údaje o přerušení transakce musí být odeslány do iEKA a musí být také uvedeny ve výkazech (viz následující kapitola).

Záznam v auditním protokolu – přerušení / zrušení transakcí

Pokud je odeslána datová náplň na POST /api/v1/transactions/cancelDocument, služba fiskalizace RetailForce automaticky vygeneruje záznam v technickém protokolu událostí / technickém deníku („auditní protokol“) typu:

DocumentCancelDocument

Záznam obsahuje součet (GrossValue) jednotlivých položek v odeslaném datovém bloku, jelikož tato informace

musí být předána iEKA a
rovněž uvedena ve zprávě (Z) a
zprávě (X).

Data se do systému iEKA přenášejí prostřednictvím dokumentu EndOfDay. Při zaúčtování denního uzávěrky se v dokumentu FiscalResponse Lithuania vrátí následující hodnoty:

„DayCanceledReceiptsDocumentsQuantity“ – počet zrušených/neuskutečněných transakcí za den
„DayCanceledReceiptsDocumentsAmount“ – (hrubá) celková částka všech zrušených / neuskutečněných transakcí

Prodej zvláštního zboží

V Litvě musí být prodej určitých druhů zboží specificky označen. Tyto prodeje se do systému iEKA vykazují jako samostatné součty a jsou rovněž zahrnuty do zpráv (zpráva (X), zpráva (Z)).

Tyto takzvané „prodeje zvláštního zboží“ zahrnují následující skupiny produktů:

Alkohol a
palivo

V RetailForce DOM lze příslušné položky odpovídajícím způsobem označit pomocí vlastnosti „itemTypeClassification“. Skupiny produktů klasifikované v Litvě jako „speciální zboží“ lze vyhledat pomocí „FiscalCountryProperties“ (vlastnost: „supportedItemTypeClassification“).

Zprávy

Pokladní systémy musí být schopny generovat následující zprávy:

Zpráva (X) – denní průběžná zpráva (známá také jako Zpráva (X))
Zpráva (Z) – denní fiskální zpráva (také známá jako Zpráva (Z))
Podrobná fiskální zpráva
Souhrnná fiskální zpráva

Zpráva	typ dokumentu	Poznámky
Zpráva (X)	98 / „[98] = CashCheck“	lze vygenerovat prostřednictvím koncového bodu GET /api/v1/closing/{clientId}/endofdayDocument, ale před odesláním datové náplně (/storeDocument) je nutné změnit následující údaje: „documentType“ > na 98 resp. „[98] = EndOfDay“ „documentTypeCaption“ > na libovolnou hodnotu; např. „Report (X)“ „documentId“ > na ID dokumentu z pokladního systému „documentNumber“ > na číslo dokladu z pokladního systému
Zpráva (Z)	99 / „[99] = EndOfDay“	lze vygenerovat prostřednictvím koncového bodu GET /api/v1/closing/{clientId}/endofdayDocument. Jako obvykle je třeba upravit následující údaje: „documentId“ > na ID dokumentu v pokladním systému „documentNumber“ > na číslo dokladu v POS systému
Podrobná daňová zpráva	-	V RetailForce neexistuje pro podrobnou finanční zprávu žádný explicitní typ dokumentu („documentType“). Tuto zprávu lze vygenerovat prostřednictvím následujících koncových bodů (libovolně): GET /api/v1/management/lithuania/{clientId}/fiscal-report-detail/{reportIdFrom}/{reportIdTo} GET /api/v1/management/lithuania/{clientId}/fiscal-report-date-detail Údaje obsažené v odpovědi slouží jako podklad pro vytvoření zprávy v tištěné podobě. Poznámka: Při volání jednoho z těchto dvou koncových bodů se zpráva vygeneruje a vrátí se do pokladního systému jako odpověď. Po volání je zpráva již odeslána do iEKA. Žádné další kroky nejsou nutné.
Souhrnná daňová zpráva	-	V RetailForce neexistuje pro souhrnnou daňovou zprávu žádný explicitní typ dokumentu („documentType“). Tuto zprávu lze vygenerovat prostřednictvím následujících koncových bodů (libovolného z nich): GET /api/v1/management/lithuania/{clientId}/fiscal-report-summary/{reportIdFrom}/{reportIdTo} GET /api/v1/management/lithuania/{clientId}/fiscal-report-date-summary Údaje obsažené v odpovědi slouží jako podklad pro vytvoření zprávy v tištěné podobě. Poznámka: Při volání jednoho z těchto dvou koncových bodů se zpráva vygeneruje a vrátí se do pokladního systému jako odpověď. Po volání je zpráva již odeslána do systému iEKA. Žádné další kroky nejsou nutné.

Další informace o tom, jaká data musí být v příslušných zprávách uvedena, naleznete v článku Požadavky na dokumenty v Litvě.

EKJ

Tento článek byl přeložen automaticky.

Zvláštní charakteristiky Litva v kostce

Předpoklady

Servisní společnost

Bezpečnostní modul

Parametr servisní společnosti

Bezpečnostní modul

Digitální certifikáty

Aktualizace nutná

Hodnoty bezpečnostního modulu

Obnovení testovacího bezpečnostního modulu

Komunikace s iEKA

Odstraňování chyb

Proces

Stav transakce

Zvláštní postupy

Vrácení / výměna zboží

Technický deník

Součty ve výkazech

Vklady a výběry

Příklady datových náplní JSON

Zrušení / přerušení transakcí

Záznam v auditním protokolu – přerušení / zrušení transakcí

Prodej zvláštního zboží

Zprávy

EKJ

Komentáře

Předpoklady

Servisní společnost

Bezpečnostní modul

Parametr servisní společnosti

Bezpečnostní modul

Digitální certifikáty

Aktualizace nutná

Hodnoty bezpečnostního modulu

Obnovení testovacího bezpečnostního modulu

Komunikace s iEKA

Odstraňování chyb

Proces

Stav transakce

Zvláštní postupy

Vrácení / výměna zboží

Technický deník

Součty ve výkazech

Vklady a výběry

Příklady datových náplní JSON

Zrušení / přerušení transakcí

Záznam v auditním protokolu – přerušení / zrušení transakcí

Prodej zvláštního zboží

Zprávy

EKJ

Související články