Ez a cikk azokat a speciális jellemzőket ismerteti, amelyeket a litván fiskalizáció keretében figyelembe kell venni, illetve amelyek a jogszabályokból és a műszaki követelményekből adódnak. A cikkben használt kifejezések és azok jelentésének áttekintése a „A litván fiskalizáció kifejezései” című cikkben található.

A tartalom áttekintése:

• Előfeltételek – mi szükséges a pénztárgép szabályszerű működéséhez?
• Biztonsági modul – mi ez, és milyen speciális funkciók kapcsolódnak hozzá?
• iEKA-kommunikáció – mit kell figyelembe venni?
• Különleges folyamatok – mik a különleges jellemzői a következőknek:
  • Visszavételek/cserék
  • Műszaki napló
  • Összegek a jelentésekben
  • Be- és kifizetések
  • Tranzakciók törlése
  • Különleges áruk értékesítése
• Jelentések – mely jelentéseket kell elkészíteni, és milyen adatokat kell tartalmazniuk?
• EKJ – mi ez és milyen követelmények vonatkoznak rá?

Előfeltételek

Ahhoz, hogy egy pénztárgépet Litvániában üzembe lehessen helyezni, a következőkre van szükség:

Service company

Csak egy tanúsított service company képviselői vehetik üzembe a pénztárgépeket, és csatlakoztathatják azokat az iEKA szolgáltatáshoz és a biztonsági modulhoz.

A service companyt a Litvánia konfigurációban lehet megadni. A service company kiválasztásához (amely a konfigurációban legördülő menüként érhető el) a distributor és a service company közötti szerződés szükséges. Miután a szerződést elmentették/aktiválták a RetailForce portalon, a service company bejegyzése elérhetővé válik a konfigurációban.

Biztonsági modul

Minden pénztárgépet tanúsított biztonsági modullal kell felszerelni. A biztonsági modul csak laza kapcsolatban áll a service company-val. Biztonsági modul vásárlásakor azonban kérjük, győződjön meg arról, hogy azt a RetailForce system is támogatja.

A biztonsági modul feladatai közé tartozik a tranzakciós adatok aláírása, a végösszeg-számláló kezelése, valamint a magán- és nyilvános kulcsok és a digitális tanúsítványok biztonságos tárolása.

Service company parameter

Miután a konfigurációban kiválasztottak egy service companyt, és azt egy entitáshoz (szervezet, vállalat, üzlet, terminal) rendelték, a service company alkalmazottja megadhatja a service company paramétereit (lásd a litván fiskalizációs feltételeket) minden egyes terminalhoz.

Ha a pénztárgép rendelkezik biztonsági modullal, és a service company paramétereit is megadták, a pénztárgép (a client) üzembe helyezhető.

Biztonsági modul

A fiskális tranzakciók adatait a RetailForce fiskalizációs szolgáltatás automatikusan aláírja a biztonsági modulon keresztül.

A biztonsági modul az inicializálás során automatikusan aktiválódik. A szükséges digitális tanúsítványok is ebbe a folyamatba kerülnek betöltésre a biztonsági modulba.

Digitális tanúsítványok

Az adatok aláírásához és egyéb célokra használt tanúsítványokat lejáratuk előtt meg kell újítani.

A tanúsítványok cseréjéhez a fiskalizációs szolgáltatás a következő funkciót biztosítja:

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

A végpont meghívásakor a fiskalizációs szolgáltatás (middleware) ellenőrzi, hogy szükséges-e a tanúsítványok cseréje. Ha egy tanúsítvány érvényességi ideje hamarosan lejár, azt egy újabbra cserélik.

Frissítés szükséges

A tanúsítványcsere csak a napi zárás/jelentés (Z) (EndOfDay dokumentum) után lehetséges. Minden EndOfDay dokumentum esetében a „certificatesUpdateRequired” tulajdonság kerül visszaadásra a fiscalResponse-ban.

Ha a „certificatesUpdateRequired” értéke = true, az upstream rendszernek kezdeményeznie kell a tanúsítványcserét a /api/v1/management/lithuania/{clientId}/certificate-update végpont POST-hívásával.

Értékek Biztonsági modul

A biztonsági modulban tárolt értékek (értékesítési számláló, pénztárgép-ID, aláírt dokumentumok száma és egyéb adatok) a következő végponton keresztül olvashatók ki

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

A tesztbiztonsági modul visszaállítása

Az éles üzemű biztonsági modulokkal ellentétben a tesztbiztonsági modulok visszaállíthatók a gyári alapértékekre. Ez különösen fontos a bevezetési fázisban, ha hibák léptek fel (pl. az iEKA-kommunikáció során – lásd alább).

A visszaállítás a következő végpont segítségével hajtható végre

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

iEKA-kommunikáció 

A tranzakciós adatok biztonsági modulon keresztüli aláírása mellett az adóhatóság online rendszerébe (iEKA) történő adatátvitel a litván fiskalizáció egyik legfontosabb követelménye.

The RetailForce system handles automatic communication with iEKA. iEKA limits the number of data records that can be transferred within a certain period of time, as well as the frequency of transfers/requests within a period of time. Emiett the fiscalisation service does not transmit data to iEKA in real time, but rather async mode.

Hibakeresés

Az adatátvitel alapjául szolgáló adatokat a fiskalizációs szolgáltatás a (pl. Windows rendszereken) C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles mappában tárolja.

Folyamat

A fent leírt mappa általában három almappát tartalmaz:

• send – Az iEKA-nak továbbítandó adatok (még nem továbbított adatok).
• accepted – Az iEKA-nak elküldött és a rendszer által elfogadott adatok.
• 20xy – Az iEKA válasza az egyes adatrekordok érvényesítése után (azt az évet jelöli, amelyben a tranzakciót rögzítették)

Az iEKA-ba történő adatátvitel a következő folyamaton megy keresztül:

1. A RetailForce client fogadja az adatokat a felülről érkező rendszertől („pénztárgép”), és
2. átalakítja azokat iEKA formátumra (JSON fájlként).
3. Ezt a JSON-fájlt a \\lithuaniaFiscalFiles\send mappában tárolja.
4. A \\send mappában található fájlokat rendszeresen (aszinkron módon) továbbítják az iEKA-szolgáltatásnak. Az átvitel előtt a JSON-fájlokat iEKA XML-formátumra konvertálják.
5. Amint az adatok megérkeznek az iEKA rendszerébe, az iEKA visszaigazolja a fogadásukat.
6. Ekkor a tranzakciós adatok az iEKA-tól kapott visszaigazolással együtt átkerülnek a \\send mappából a \\accepted mappába.
   1. Ha az adatok nem tudtak átkerülni az iEKA-ba, azok a \\send mappában maradnak, és a fiskalizációs szolgáltatás később megpróbálja átvinni őket.
7. Az iEKA-rendszer ezután ellenőrzi az átvitt adatokat. Az ellenőrzés állapotát az adatátviteli modulnak (fiskalizációs szolgáltatásnak) aktívan le kell kérdeznie.
8. Ezt a lekérdezést az iEKA oldalán fennálló kommunikációs korlátozások miatt (lásd fent) rendszeres időközönként is elvégzik.
9. Az érvényesítési állapot lekérdezésének eredményét a 20xy mappába tárolják (az adatokat a \\accepted mappából a \\20xy mappába helyezik át).

Tranzakciós állapot

A feljebb lévő rendszerek („pénztárgépek”) a következő funkciók segítségével ellenőrizhetik az egyes tranzakciók állapotát:

• GET /api/v1/management/lithuania/{clientId}/check-document-status-by-ieka-document-number/{iekaDocumentNumber} és
• GET /api/v1/management/lithuania/{clientId}/check-document-status-by-document-number/{DocumentNumber}

Különleges folyamatok

Áruk visszavétele / cseréje

A visszavételek (pl. árucsere) Litvániában nem adóügyi dokumentumoknak, azaz nem adóügyi tranzakcióknak minősülnek. Ezeket továbbítják az iEKA rendszerbe, de a biztonsági modulon keresztül nem írják alá őket. Ez azt is jelenti, hogy a visszavételi dokumentumok nem befolyásolják a biztonsági modul értékesítési (összérték) számlálóit.

Ahhoz, hogy a RetailForce system helyesen ismerje fel a visszavételeket, a következő tulajdonságokat kell beállítani:

• „documentType”: 0 / „[0] = Nyugta”
• „cancellationDocument”: true
• „documentReference” – be kell állítani egy másik dokumentumra (az eredeti értékesítési dokumentumra) való hivatkozást
• Negatív tranzakciós értékek („GrossValue”, „NetValue”, „TaxValue”, „Amount”)

Műszaki napló

Litvániában a műszaki folyamatokat rögzíteni kell. Más országokhoz hasonlóan ez a műszaki eseménynapló / műszaki napló vagy az AuditLog segítségével történik.

Különösen a következő eseményeket kell rögzíteni:

• Pénztárgép kinyitása (DrawerOpen) – ezt az előzetes rendszernek kell továbbítania.
• Dokumentum törlése (DocumentCancelDocument) – automatikusan rögzítésre kerül.

További részletekért lásd a „Műszaki események Litvániában” című cikket.

Összegek a jelentésekben

A jelentésekben (Z jelentés – napi pénzügyi jelentés, X jelentés – napi közbenső jelentés) bizonyos (összesített) összegeket külön kell feltüntetni. Ennek biztosítása érdekében bizonyos szabályokat be kell tartani az adatok átvitelekor a forrásrendszer („pénztárgépek”) és a pénzügyi szolgáltatás között.

A részleteket lásd a „Összegzés a jelentésekben – Litvánia” című cikkben.

PayIn és kifizetés

A litván fiskalizációs előírások szerint a pénztárgépben (pénztárfiókban) lévő készpénzegyenleget továbbítani kell az iEKA-nak. Ennek biztosítása érdekében a befizetési és kifizetési tranzakciókat (pl. visszajáró befizetéseket) is továbbítani kell az upstream rendszerből a RetailForce fiskalizációs szolgáltatásba (middleware) PayIn és PayOut dokumentumok formájában („documentType”: 11 / „[11] = PayIn” és „documentType”: 10 / „[10] = PayOut”, „BusinessTransactionType”: „[90] = MoneyTransfer” értékekkel).

A PayIn és PayOut műveletekkel kapcsolatban a következőket kell figyelembe venni:

Példák JSON payload-okra

PayIn:

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

Tranzakciók megszakítása / elállás

A tranzakció befejezése előtti bármilyen megszakítást Litvániában nyilvántartásba kell venni. Az

• POST /api/v1/transactions/cancelDocument

végpontot használják erre a célra.

Az átvitt JSON payload tartalmaznia kell

• a megszakítás pillanatáig rögzített összes pozíciót, de
• egy üres „Payments” objektumot.

Példa:

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

A tranzakció megszakítására vonatkozó adatokat el kell küldeni az iEKA-nak, és azokat a jelentésekben is fel kell tüntetni (lásd a következő fejezetet).

Auditnapló-bejegyzés: tranzakciók megszakítása / elvetése

Ha egy hasznos payload-t küldenek a POST /api/v1/transactions/cancelDocument címre, a RetailForce adóügyi szolgáltatás automatikusan létrehoz egy bejegyzést a technikai eseménynaplóban / technikai naplóban („auditnapló”) a következő típusú bejegyzést:

• DocumentCancelDocument

A bejegyzés tartalmazza a továbbított payload egyes tételeinek összegét (GrossValue), mivel ezt az információt

• az iEKA-nak továbbítani kell, és
• valamint szerepelnie kell a jelentésben (Z) és
• az (X) jelentésben is szerepelnie kell.

Az adatokat az EndOfDay dokumentumon keresztül továbbítják az iEKA-nak. A napi zárás könyvelésekor a következő értékek kerülnek visszaadásra a litván fiscalResponse-ban:

• „DayCanceledReceiptsDocumentsQuantity” – a tranzakciók naponta törölt/megszakított darabszáma
• „DayCanceledReceiptsDocumentsAmount” – az összes tranzakció-megszakítás / elvetés (bruttó) összege

Különleges áruk értékesítése

Litvániában bizonyos áruk értékesítését külön kell jelölni. Ezeket az értékesítéseket külön összegekként jelentik be az iEKA rendszerbe, és szerepelnek a jelentésekben is (X. jelentés, Z. jelentés).

Ezek az úgynevezett „különleges áruk értékesítései” a következő termékcsoportokat foglalják magukban:

• Alkohol és
• üzemanyag

A RetailForce DOM-ban a vonatkozó tételek az „ItemTypeClassification” tulajdonság segítségével jelölhetők meg. A Litvániában „különleges áruknak” minősített termékcsoportok a „fiscalCountryProperties” (tulajdonság: „supportedItemTypeClassification”) segítségével lekérdezhetők.

Jelentések

A pénztárgép-rendszereknek képesnek kell lenniük a következő jelentések generálására:

• (X) jelentés – napi közbenső jelentés (más néven (X) jelentés)
• (Z) jelentés – napi pénzügyi jelentés (más néven (Z) jelentés)
• Részletes pénzügyi jelentés
• Összefoglaló pénzügyi jelentés

További információk arról, hogy milyen adatokat kell tartalmazniuk az egyes jelentéseknek, a „Dokumentumkövetelmények Litvánia” című cikkben találhatók.

EKJ

Ezt a cikket automatikusan lefordították.