Šiame straipsnyje aprašomos ypatybės, į kurias reikia atsižvelgti įgyvendinant Lietuvos fiskalizaciją, arba kurios kyla iš įstatymų ir techninių reikalavimų. Šiame straipsnyje vartojamų terminų ir jų reikšmių apžvalgą rasite straipsnyje „Lietuvos fiskalizacijos terminai“.

Turinys:

Reikalavimai – ko reikia, kad kasos sistema veiktų pagal reikalavimus?
Saugumo modulis – kas tai yra ir kokios specialios funkcijos su juo susijusios?
iEKA ryšys – į ką reikia atkreipti dėmesį?
Specialūs procesai – kokios ypatybės būdingos:
- grąžinimų/keitimų
- Techninis žurnalas
- Ataskaitų sumų skaičiavimas
- Įmokos ir išmokos
- Sandorio nutraukimas
- Specialių prekių pardavimas
Ataskaitos – kokios ataskaitos turi būti rengiamos ir kokie duomenys turi būti jose pateikiami?
EKJ – kas tai yra ir kokie yra reikalavimai?

Reikalavimai

Kad Lietuvoje būtų galima pradėti naudoti kasos aparatą, reikalinga:

Aptarnavimo įmonė

Tik sertifikuotos paslaugų bendrovės atstovai gali pradėti naudoti kasos aparatus ir prijungti juos prie iEKA paslaugos bei saugumo modulio.

Paslaugų įmonę galite nustatyti per konfigūraciją „Lietuva“. Kad būtų galima pasirinkti paslaugų įmonę (ji turi būti prieinama kaip išskleidžiamasis elementas konfigūracijoje), būtina sudaryti sutartį tarp platintojo ir paslaugų įmonės. Įkėlus/aktyvavus sutartį „RetailForce“ portale, konfigūracijoje atsiranda paslaugų teikėjo įrašas.

Saugumo modulis

Kiekviena kasos aparatas turi būti įrengtas sertifikuotu saugumo moduliu. Saugumo modulis su paslaugų teikėja susijęs tik iš dalies. Tačiau įsigydami saugumo modulį atkreipkite dėmesį, kad jis būtų suderinamas su „RetailForce“ sistema.

Saugumo modulio užduotys yra, be kita ko, sandorių duomenų pasirašymas, sumų skaitiklių valdymas, taip pat privačių ir viešųjų raktų bei skaitmeninių sertifikatų saugus laikymas.

Dėmesio: kasos aparatų gedimai (kasos keitimas, aparatinės įrangos keitimas ir pan.) visada reikalauja naujo saugumo modulio įsigijimo. Saugumo modulio tolesnis naudojimas kitame kasos aparate / aparatinėje įrangoje techniškai nėra numatytas.

Paslaugų bendrovės parametrai

Pasirinkus paslaugų įmonę konfigūracijoje ir priskyrus konfigūraciją atitinkamam subjektui (organizacijai, įmonei, parduotuvei, terminalui), paslaugų įmonės darbuotojas gali įvesti vadinamuosius paslaugų įmonės parametrus (žr. Lietuvos fiskalizacijos terminus) kiekvienam terminalui.

Jei kasos aparatas turi saugumo modulį ir buvo įvesti paslaugų bendrovės parametrai, kasos aparatas (klientas) gali būti pradėtas eksploatuoti.

Pastaba: Mes mielai padėsime Jums susisiekti su Lietuvos paslaugų įmone bei įsigyti suderinamą saugumo modulį.

Saugumo modulis

Fiskalinių operacijų duomenys automatiškai pasirašomi „RetailForce“ fiskalizacijos paslaugos per saugumo modulį.

Saugumo modulis aktyvuojamas automatiškai paleidimo (inicijavimo) metu. Tuo pačiu metu į saugumo modulį įkeliamos reikiamos skaitmeninės sertifikatai.

Skaitmeniniai sertifikatai

Sertifikatų, naudojamų duomenų pasirašymui ir kitiems tikslams, galiojimo laikas turi būti pratęstas prieš pasibaigiant jų galiojimo terminui.

Sertifikatams pakeisti fiskalizacijos paslauga teikia funkciją:

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

Kai kreipiamasi į šį tašką, fiskalizacijos paslauga (tarpinė programinė įranga) patikrina, ar reikia keisti sertifikatus. Jei sertifikato galiojimo laikas artėja prie pabaigos, sertifikatas pakeičiamas naujesniu.

Atnaujinimas būtinas

Sertifikato keitimas galimas tik po dienos užbaigimo / ataskaitos (Z) (EndOfDay dokumento). Kiekviename EndOfDay dokumente fiscalResponse grąžinama savybė „certificatesUpdateRequired“.

Jei „certificatesUpdateRequired“ vertė yra „true“, pirminė sistema turi inicijuoti sertifikato keitimą naudodama galinį tašką POST /api/v1/management/lithuania/{clientId}/certificate-update.

Saugumo modulio reikšmės

Šiuo metu saugumo modulyje esančias vertes (apyvartos skaitiklį, kasos ID, pasirašytų dokumentų skaičių ir kt.) galima gauti naudojant galinį tašką

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

Testinio saugumo modulio atstatymas

Bandomieji saugumo moduliai, skirtingai nei tikrojo veikimo saugumo moduliai, gali būti atkurti į gamyklinius nustatymus. Tai ypač svarbu diegimo etape, jei, pavyzdžiui, įvyko klaidų (pvz., iEKA ryšyje – žr. toliau).

Atstatymas atliekamas naudojant galinį tašką

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

Dėmesio: jei saugumo modulis atstatomas, „RetailForce Cloud“ taip pat reikia sukurti naują terminalą arba inicijuoti naują klientą (nepamirškite įvesti „Service Company“ parametrų!).

iEKA ryšys

Be sandorių duomenų pasirašymo per saugumo modulį, duomenų perdavimas į Finansų administracijos internetinę sistemą (iEKA) yra vienas iš pagrindinių Lietuvos fiskalizacijos reikalavimų.

„RetailForce“ sistema automatiškai užtikrina ryšį su iEKA. Tuo tarpu iEKA riboja duomenų įrašų skaičių per tam tikrą laikotarpį arba perdavimo / užklausų (prašymų) dažnumą per tam tikrą laikotarpį. Dėl šios priežasties fiskalizacijos paslauga duomenis į iEKA perduoda ne realiuoju laiku, o asinchroniškai.

Debugging

Duomenis, kurie naudojami kaip duomenų perdavimo pagrindas, fiskalizacijos paslauga saugo aplanke (pvz., „Windows“ sistemose) C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles.

Struktūra

Pirmiau aprašytame aplanke paprastai yra 3 pakatalogiai:

send – duomenys, kurie dar nebuvo perduoti į iEKA
accepted – duomenys, kurie buvo nusiųsti į iEKA ir iš esmės buvo priimti sistemos.
20xy – iEKA atsakymas po kiekvieno atskiro duomenų įrašo patvirtinimo (nurodo metus, kuriais buvo užregistruota operacija)

Duomenų perdavimas į iEKA vyksta taip:

„RetailForce Client“ gauna duomenis iš pirminės sistemos („kasos aparato“) ir
konvertuoja juos į iEKA formatą kaip JSON failą.
Šis JSON failas yra išsaugomas aplanke \\lithuaniaFiscalFiles\send.
Aplankelyje \\send esantys failai periodiškai (asinchroniškai) perduodami į iEKA paslaugą. Prieš perdavimą JSON failai konvertuojami į iEKA XML formatą.
Kai tik duomenys patenka į iEKA sistemą, iEKA patvirtina jų gavimą.
Tuo metu sandorių duomenys iš aplanko \\send perkeliami į aplanką \\accepted kartu su iEKA gavimo patvirtinimu.
1. Jei duomenų nepavyko perduoti į iEKA, jie lieka aplanke \\send, o fiskalizacijos tarnyba vėliau bandys juos perduoti dar kartą.
Dabar iEKA sistema atlieka perduotų duomenų patikrinimą. Patvirtinimo būseną turi aktyviai užklausti duomenų perdavimo modulis (fiskalizacijos tarnyba)
Šis užklausimas taip pat atliekamas periodiškai, dėl iEKA ryšio apribojimų (žr. aukščiau).
Patvirtinimo būsenos užklausos rezultatas pateikiamas aplanke 20xy (duomenys perkeliami iš \\accepted į \\20xy).

Sandorio statusas

Priešsistemos („kasos aparatai“) gali patikrinti atskirų sandorių būseną naudodamos funkcijas:

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

Pastaba: Atkreipkite dėmesį, kad dėl iEKA ryšio apribojimų gali praeiti iki 10 min., kol bus pateikta konkretaus dokumento būsena.

Specialūs procesai

Grąžinimai / keitimai

Grąžinimai (pvz., prekių keitimas) Lietuvoje yra vadinamieji neapmokestinami dokumentai, t. y. neapmokestinamos operacijos. Jie perduodami į iEKA sistemą, tačiau nėra pasirašomi per saugumo modulį. Tai taip pat reiškia, kad grąžinimo dokumentai neturi įtakos saugumo modulio apyvartos skaitikliams.

Kad „RetailForce“ sistema teisingai atpažintų grąžinimus kaip tokius, reikia nustatyti šias savybes:

„documentType“: 0 / „[0] = Receipt“
„cancellationDocument“: true
„documentReference“ – turi būti nustatyta nuoroda į kitą dokumentą (pirminį pardavimo dokumentą)
neigiamos sandorio vertės („GrossValue“, „NetValue“, „TaxValue“, „Amount“)

Pastaba: šis žymėjimas nėra būdingas tik Lietuvai, bet galioja visose šalyse. Tačiau Lietuvoje pardavimai ir grąžinimai turi būti perduodami fiskalizacijos tarnybai atskirai (žr. fiscalCountryProperty: „returnAndSaleBehavior“: „multiReceipt“).

Dėmesio: dėl grąžinimų taip pat atkreipkite dėmesį į straipsnį „Sumų skaičiavimas ataskaitose Lietuvoje“.

Techninis žurnalas

Lietuvoje turi būti registruojami techniniai įvykiai. Kaip ir kitose šalyse, tai atliekama naudojant vadinamąjį techninių įvykių protokolą / techninį žurnalą arba „AuditLog“.

Ypač turi būti registruojami šie įvykiai:

Kassos stalčiaus atidarymas (DrawerOpen) – turi būti perduodamas iš pirminės sistemos.
Kvitų atšaukimas (DocumentCancelDocument) – registruojamas automatiškai.

Išsamią informaciją apie tai rasite straipsnyje „Techniniai įvykiai Lietuvoje“.

Sumų apskaičiavimas ataskaitose

Ataskaitose (Ataskaita (Z) – kasdienė fiskalinė ataskaita, Ataskaita (X) – kasdienė tarpinė ataskaita) tam tikros sumos turi būti nurodytos atskirai. Kad tai būtų užtikrinta, duomenų perdavimo tarp išorinės sistemos („kasos aparatų“) ir fiskalinės paslaugos metu reikia laikytis tam tikrų taisyklių.

Išsamią informaciją apie tai rasite straipsnyje „Sumų skaičiavimas ataskaitose Lietuvoje“.

Įplaukos ir išmokos

Pagal Lietuvos fiskalizacijos reikalavimus kasos grynųjų pinigų likutis turi būti perduodamas į iEKA. Kad tai būtų užtikrinta, įmokos ir išmokos (pvz., grąžos įnešimas) taip pat turi būti perduodamos iš pirminės sistemos į „RetailForce“ fiskalizacijos paslaugą (tarpinę programinę įrangą) kaip „PayIn“ ir „PayOut“ dokumentai („documentType“: 11 / „[11] = PayIn“ ir „documentType“: 10 / „[10] = PayOut“ su „businessTransactionType“: „[90] = MoneyTransfer“).

Atliekant „PayIn“ ir „PayOut“ operacijas, reikia atsižvelgti į šiuos dalykus:

documentType

Procesas

Vertės

11 / „[11] = PayIn“

Dabartinis kasos grynųjų pinigų likutis turi būti perduotas kaip pirmoji dienos operacija.

Ankstesnės dienos grynųjų pinigų likutis po dienos uždarymo (EndOfDay) NEPERDUODAMAS, o yra lygus „0“.

Per dieną galima atlikti bet kokį skaičių įmokų. Grynųjų pinigų likutis visada automatiškai koreguojamas.

Pastaba: vietoj pirmojo dienos „PayIn“ dokumento, žinoma, taip pat galima perduoti dokumento tipo „[90] = OpeningBalance“ su „businessTransactionType“: „[90] = MoneyTransfer“.

Visos reikšmės („GrossValue“, „Amount“) turi būti TEIGIAMOS.

10 / „[10] = PayOut“

PRIEŠ „EndOfDay“ dokumentą (dienos pabaigą) visas grynųjų pinigų likutis turi būti nustatytas į 0 naudojant „PayOut“. Tai būtina, nes likutis nėra perkeltas į kitą dieną.

Dėmesio: jei išmoka nebus atlikta, iEKA bus pranešta apie neteisingą grynųjų pinigų likutį!

Per dieną galima atlikti bet kiek išmokėjimų. Grynųjų pinigų likutis visada koreguojamas automatiškai.

Visos reikšmės („GrossValue“, „Amount“) turi būti NEIGIAMOS.

JSON duomenų pavyzdžiai

„PayIn“:

(Versija: 1.11.4; DOM versija 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:

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

Sandorio nutraukimas

Sandorio nutraukimas prieš jo užbaigimą Lietuvoje turi būti užregistruotas. Tam naudojamas galinis taškas

POST /api/v1/transactions/cancelDocument

Pateiktame JSON duomenų bloke turi būti

apimti visas iki nutraukimo užregistruotas pozicijas, tačiau
tuščią „Payments“ objektą.

Pavyzdys:

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

Duomenys apie sandorių nutraukimus turi būti perduoti iEKA ir taip pat nurodyti ataskaitose (žr. tolesnį skyrių).

Audito žurnalo įrašas „Sandorio nutraukimas“

Jei duomenų paketas perduodamas POST /api/v1/transactions/cancelDocument, „RetailForce“ fiskalizacijos paslauga automatiškai sukuria įrašą techniniame įvykių žurnale („Auditlog“) tokio tipo:

DocumentCancelDocument

Įraše nurodoma perduoto duomenų paketo atskirų pozicijų suma (GrossValue), nes ši informacija

perduodama iEKA ir
taip pat turi būti pateikta ataskaitoje (Z) bei
ataskaitoje (X).

Duomenys į iEKA perduodami per „EndOfDay“ dokumentą. Įrašius dienos uždarymą, „FiscalResponse“ (Lietuva) grąžinamos šios reikšmės:

„DayCanceledReceiptsDocumentsQuantity“ – sandorių nutraukimų skaičius per dieną
„DayCanceledReceiptsDocumentsAmount“ – visų nutrauktų sandorių (bruto) suma

Ypatingų prekių pardavimas

Lietuvoje tam tikrų prekių pardavimas turi būti specialiai pažymėtas. Pardavimai perduodami į iEKA sistemą kaip atskiri sumos, taip pat nurodomi ataskaitose (Ataskaita (X), Ataskaita (Z)).

Šis vadinamasis „Special Goods Sales“ apima šias prekių grupes:

alkoholį ir
Kuras

„RetailForce DOM“ sistemoje atitinkami prekės vienetai gali būti atitinkamai pažymėti naudojant savybę „itemTypeClassification“. Kokios prekių grupės Lietuvoje laikomos „Special Goods“, galima sužinoti naudojant „FiscalCountryProperties“ (savybė: „supportedItemTypeClassification“).

Ataskaitos

Kasinės sistemos turi gebėti generuoti šias ataskaitas:

Ataskaita (X) – kasdienė tarpinė ataskaita (taip pat ataskaita (X))
Ataskaita (Z) – kasdienė fiskalinė ataskaita (taip pat ataskaita (Z))
Išsami fiskalinė ataskaita
Apibendrinanti fiskalinė ataskaita

Ataskaita	documentType	Pastabos
Ataskaita (X)	98 / „[98] = CashCheck“	gali būti sukurtas per galinį tašką GET /api/v1/closing/{clientId}/endofdayDocument, tačiau prieš perduodant duomenų paketą (/storeDocument) reikia pakeisti šiuos duomenis: „documentType“ > į 98 arba „[98] = EndOfDay“ „documentTypeCaption“ > bet koks; pvz., „Ataskaita (X)“ „documentId“ > į kasos sistemos dokumento ID „documentNumber“ > į kasos sistemos dokumento numerį
Ataskaita (Z)	99 / "[99] = EndOfDay"	gali būti sukurtas per galinį tašką GET /api/v1/closing/{clientId}/endofdayDocument. Kaip įprasta, reikia pritaikyti šiuos duomenis: „documentId“ > į kasos sistemos dokumento ID „documentNumber“ > į kasos sistemos dokumento numerį
Išsami fiskalinė ataskaita	-	Išsamiai fiskalinei ataskaitai „RetailForce“ nėra numatyto konkretaus dokumento tipo („documentType“). Šią ataskaitą galima sukurti naudojant šiuos galinius taškus (pasirinktinai): GET /api/v1/management/lithuania/{clientId}/fiscal-report-detail/{reportIdFrom}/{reportIdTo} GET /api/v1/management/lithuania/{clientId}/fiscal-report-date-detail Atsakyme pateikti duomenys naudojami kaip pagrindas ataskaitai spausdinti. Pastaba: iškvietus vieną iš dviejų galinių taškų, ataskaita sukurta ir kaip atsakymas grąžinama į kasos sistemą. Iškvietus ataskaita jau perduodama į iEKA. Jokių papildomų veiksmų atlikti nebūtina.
Apibendrinanti fiskalinė ataskaita	-	RetailForce sistemoje nėra aiškaus apibendrinamosios fiskalinės ataskaitos dokumento tipo („documentType“). Šią ataskaitą galima sukurti per šiuos galinius taškus (pasirenkamai): GET /api/v1/management/lithuania/{clientId}/fiscal-report-summary/{reportIdFrom}/{reportIdTo} GET /api/v1/management/lithuania/{clientId}/fiscal-report-date-summary Atsakyme pateikti duomenys yra pagrindas ataskaitos spausdinimui. Pastaba: iškvietus vieną iš dviejų galinių taškų, ataskaita sukurta ir kaip atsakymas grąžinama į kasos sistemą. Iškvietus ataskaita jau perduodama į iEKA. Jokių papildomų veiksmų atlikti nebūtina.

Daugiau informacijos apie tai, kokie duomenys turi būti įtraukti į atitinkamas ataskaitas, rasite straipsnyje „Dokumentų reikalavimai Lietuvoje“.

EKJ

Lietuvos ypatumai iš pirmo žvilgsnio

Reikalavimai

Aptarnavimo įmonė

Saugumo modulis

Paslaugų bendrovės parametrai

Saugumo modulis

Skaitmeniniai sertifikatai

Atnaujinimas būtinas

Saugumo modulio reikšmės

Testinio saugumo modulio atstatymas

iEKA ryšys

Debugging

Struktūra

Sandorio statusas

Specialūs procesai

Grąžinimai / keitimai

Techninis žurnalas

Sumų apskaičiavimas ataskaitose

Įplaukos ir išmokos

JSON duomenų pavyzdžiai

Sandorio nutraukimas

Audito žurnalo įrašas „Sandorio nutraukimas“

Ypatingų prekių pardavimas

Ataskaitos

EKJ

Komentarai

Reikalavimai

Aptarnavimo įmonė

Saugumo modulis

Paslaugų bendrovės parametrai

Saugumo modulis

Skaitmeniniai sertifikatai

Atnaujinimas būtinas

Saugumo modulio reikšmės

Testinio saugumo modulio atstatymas

iEKA ryšys

Debugging

Struktūra

Sandorio statusas

Specialūs procesai

Grąžinimai / keitimai

Techninis žurnalas

Sumų apskaičiavimas ataskaitose

Įplaukos ir išmokos

JSON duomenų pavyzdžiai

Sandorio nutraukimas

Audito žurnalo įrašas „Sandorio nutraukimas“

Ypatingų prekių pardavimas

Ataskaitos

EKJ

Susiję straipsniai