Tento článok opisuje špeciálne funkcie, ktoré je potrebné zohľadniť v kontexte litovskej fiskalizácie alebo ktoré vyplývajú zo zákonov a technických požiadaviek. Prehľad pojmov použitých v tomto článku a ich významov nájdete v článku Pojmy litovskej fiskalizácie.

Prehľad obsahu:

Predpoklady – čo je potrebné na prevádzku pokladnice v súlade s predpismi?
Bezpečnostný modul – čo to je a aké špeciálne funkcie sú s ním spojené?
Komunikácia iEKA – čo je potrebné zohľadniť?
Špeciálne procesy – aké sú špeciálne vlastnosti:
- Vrátenie tovaru/výmena
- Technický denník
- Súhrny v správach
- Vklady a výbery
- Zrušenie transakcie
- Predaj špeciálneho tovaru
Správy – ktoré správy je potrebné vygenerovať a aké údaje musia obsahovať?
EKJ – čo to je a aké sú požiadavky?

Predpoklady

Aby bolo možné uviesť pokladňu do prevádzky v Litve, je potrebné splniť nasledujúce podmienky:

Service company

Pokladnice môžu uvádzať do prevádzky a pripájať ich k službe iEKA a bezpečnostnému modulu iba zástupcovia certifikovanej service company.

Servisnú spoločnosť môžete definovať prostredníctvom konfigurácie Litva. Na výber servisnej spoločnosti je potrebná zmluva medzi distribútorom a servisnou spoločnosťou (dostupná ako položka v roletovom menu v konfigurácii). Akonáhle je zmluva uložená/aktivovaná v RetailForce portal, v konfigurácii je k dispozícii záznam o servisnej spoločnosti.

Bezpečnostný modul

Každá pokladňa musí byť vybavená certifikovaným bezpečnostným modulom. Bezpečnostný modul má so service company len voľnú súvislosť. Pri nákupe bezpečnostného modulu sa však uistite, že je podporovaný aj RetailForce systemom.

Medzi úlohy bezpečnostného modulu patrí podpisovanie údajov o transakciách, správa počítadla celkových súčtov a bezpečné ukladanie súkromných a verejných kľúčov a digitálnych certifikátov.

Upozornenie: Poruchy pokladníc (výmena pokladnice, výmena hardvéru atď.) vždy vyžadujú nákup nového bezpečnostného modulu. Ďalšie používanie bezpečnostného modulu na inej pokladnici/hardvéri nie je technicky možné.

Parameter service company

Po výbere service company v konfigurácii a jej priradení k subjektu (organizácii, spoločnosti, predajni, terminálu) môže zamestnanec service company zadať parametre service company (pozri Podmienky litovskej fiskalizácie) pre každý terminal.

Ak má pokladňa bezpečnostný modul a boli zadané parametre service company, pokladňu (clienta) je možné uviesť do prevádzky.

Poznámka: Radi vám pomôžeme s kontaktovaním litovskej service company a so zaobstaraním kompatibilného bezpečnostného modulu.

Bezpečnostný modul

Údaje z fiskálnych transakcií sú automaticky podpisované službou fiskalizácie RetailForce prostredníctvom bezpečnostného modulu.

Bezpečnostný modul sa aktivuje automaticky počas inicializácie. Počas tohto procesu sa do bezpečnostného modulu nahrajú aj potrebné digitálne certifikáty.

Digitálne certifikáty

Certifikáty používané na podpisovanie údajov a na iné účely je potrebné obnoviť pred uplynutím ich platnosti.

Na výmenu certifikátov poskytuje služba fiskalizácie funkciu:

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

Pri volaní tohto koncového bodu služba fiskalizácie (middleware) skontroluje, či je potrebné certifikáty vymeniť. Ak sa platnosť certifikátu blíži ku koncu, nahradí sa novším.

Aktualizácia je potrebná

Výmena certifikátov je možná až po dennom uzávierkovom hlásení (Z) (dokument EndOfDay). Pre každý dokument EndOfDay sa vo fiscalResponse vráti vlastnosť „certificatesUpdateRequired“.

Ak je hodnota „certificatesUpdateRequired“ = true, nadriadený systém musí iniciovať výmenu certifikátov pomocou koncového bodu POST /api/v1/management/lithuania/{clientId}/certificate-update.

Hodnoty bezpečnostného modulu

Hodnoty uložené v bezpečnostnom module (predajný pult, ID pokladne, počet podpísaných dokumentov a iné) je možné načítať pomocou koncového bodu

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

Obnovenie testovacieho bezpečnostného modulu

Na rozdiel od bezpečnostných modulov pre prevádzku v reálnom prostredí je možné testovacie bezpečnostné moduly obnoviť na továrenské nastavenia. To je obzvlášť dôležité počas fázy implementácie, ak došlo k chybám (napr. v komunikácii s iEKA – pozri nižšie).

Reset sa vykonáva pomocou koncového bodu

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

Upozornenie: Ak sa bezpečnostný modul obnoví, je potrebné vytvoriť aj nový terminal v RetailForce Cloud, resp. inicializovať nového klienta (nezabudnite zadať parametre service company!).

Komunikácia s iEKA

Okrem podpisovania transakčných údajov prostredníctvom bezpečnostného modulu je prenos údajov do online systému daňových orgánov (iEKA) jednou z kľúčových požiadaviek litovskej fiskalizácie.

The RetailForce system ensures automatic communication with iEKA. iEKA limits the number of data records that can be transferred in a certain time period, as well as the frequency of transfers/requests in a certain time period. Therefore, the fiscalisation service does not transmit data to iEKA in real time, but rather asynchrونnly.

Odstraňovanie chýb

Údaje, ktoré slúžia ako základ pre prenos údajov, ukladá služba fiskalizácie do priečinka (napr. v systémoch Windows) C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles.

Postup

Vyššie uvedený priečinok zvyčajne obsahuje tri podpriečinky:

send – údaje, ktoré sa majú preniesť do iEKA (údaje, ktoré ešte neboli prenesené).
accepted – údaje, ktoré boli odoslané do iEKA a boli systémom prijaté.
20xy – odpoveď od iEKA po overení údajov pre každý jednotlivý záznam (predstavuje rok, v ktorom bola transakcia zaznamenaná)

Prenos údajov do iEKA prebieha nasledovne:

RetailForce Client prijíma údaje z nadradeného systému („pokladňa“) a
prevádza ich do formátu iEKA (avšak ako súbor JSON).
Tento súbor JSON sa ukladá do zložky \\lithuaniaFiscalFiles\send.
Súbory v zložke \\send sa pravidelne (asynchrónne) odosielajú do služby iEKA. Pred odoslaním sa súbory JSON prevádzajú do formátu iEKA XML.
Akonáhle údaje dorazia do systému iEKA, iEKA potvrdí ich prijatie.
V tomto momente sa údaje o transakciách presunú zo zložky \\send do zložky \\accepted spolu s potvrdením prijatým od iEKA.
1. Ak sa údaje nepodarilo preniesť do iEKA, zostanú v zložke \\send a služba fiskalizácie sa pokúsi o ich prenos neskôr.
Systém iEKA teraz overuje prenesené údaje. Stav overovania musí modul prenosu údajov (služba fiskalizácie) aktívne zisťovať.
Toto overovanie sa vykonáva aj pravidelne z dôvodu obmedzení komunikácie zo strany iEKA (pozri vyššie).
Výsledok dotazu na stav overenia sa uloží do zložky 20xy (údaje sa presunú zo zložky \\accepted do zložky \\20xy).

Stav transakcie

Nadväzujúce systémy („pokladnice“) môžu skontrolovať stav jednotlivých transakcií pomocou nasledujúcich funkcií:

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: Upozorňujeme, že vzhľadom na komunikačné obmedzenia zo strany iEKA môže trvať až 10 minút, kým pokladňa bude môcť zistiť stav konkrétneho dokumentu.

Špeciálne procesy

Vrátenie / výmena tovaru

Vrátenie tovaru (napr. výmena tovaru) sa v Litve považuje za nefiskálny dokument, t. j. za nefiskálnu transakciu. Tieto dokumenty sa odosielajú do systému iEKA, ale nie sú podpisované prostredníctvom bezpečnostného modulu. To tiež znamená, že dokumenty o vrátení tovaru nemajú vplyv na počítadlá predaja (celkový súčet) bezpečnostného modulu.

Aby systém RetailForce správne rozpoznal vrátenia tovaru ako také, musia byť nastavené nasledujúce vlastnosti:

„documentType“: 0 / „[0] = Potvrdenka“
„cancellationDocument“: true
„documentReference“ – musí byť nastavený odkaz na iný dokument (pôvodný predajný dokument)
Záporné hodnoty transakcií („GrossValue“, „NetValue“, „TaxValue“, „Amount“)

Poznámka: Toto označenie NIE JE špecifické pre Litvu, ale platí vo všetkých krajinách. Predaj a vrátenie tovaru v Litve sa však musia hlásiť ako samostatné dokumenty do služby fiskalizácie (pozri fiscalCountryProperties: „returnAndSaleBehavior“: „multiReceipt“).

Pozor: V prípade vrátenia tovaru si prečítajte aj článok Súhrn v správach – Litva!

Technický denník

V Litve sa musia zaznamenávať technické procesy. Rovnako ako v iných krajinách sa to vykonáva pomocou Technického protokolu udalostí / Technického denníka alebo AuditLogu.

Zaznamenávať sa musia najmä nasledujúce udalosti:

Otvorenie pokladničnej zásuvky (DrawerOpen) – musí byť odoslané nadradeným systémom.
Zrušenie dokladu (DocumentCancelDocument) – zaznamenáva sa automaticky.

Ďalšie podrobnosti nájdete v článku Technické udalosti v Litve.

Súčty v správach

V správach (správa (Z) – denná fiškálna správa, správa (X) – denná priebežná správa) musia byť určité (celkové) súčty uvedené samostatne. Na zabezpečenie toho je potrebné dodržiavať určité pravidlá pri prenose údajov medzi zdrojovým systémom („pokladnice“) a fiškálnou službou.

Podrobnosti nájdete v článku Súhrny v správach Litva.

PayIn a výbery

Litovská fiskalizácia vyžaduje, aby bol stav hotovosti v pokladni (zásuvke) odoslaný do systému iEKA. Na zabezpečenie toho musia byť transakcie vkladov a výberov (napr. vklady drobných) takisto odoslané zo zdrojového systému do fiskalizačnej služby RetailForce (middleware) vo forme dokumentov PayIn a PayOut („documentType“: 11 / „[11] = PayIn“ a „documentType“: 10 / „[10] = PayOut“ s „BusinessTransactionType“: „[90] = MoneyTransfer“).

V súvislosti s platbami PayIn a PayOut je potrebné zohľadniť nasledujúce:

Poznámka: Nasledujúci popis postupu spracovania hotovostného zostatku je dočasným riešením!

documentType

Proces

Hodnoty

11 / „[11] = PayIn“

Aktuálny zostatok hotovosti v pokladni sa musí odoslať ako prvá transakcia dňa.

Zostatok hotovosti z predchádzajúceho dňa sa po uzávierke dňa (EndOfDay) NEPREVÁDZA, ale nastaví sa na „0“.

Počas dňa je možné uskutočniť ľubovoľný počet vkladov. Zostatok hotovosti sa vždy automaticky upraví.

Poznámka: Namiesto prvého dokladu PayIn dňa môžete samozrejme odoslať aj doklad typu „[90] = OpeningBalance“ s „BusinessTransactionType“: „[90] = MoneyTransfer“.

Všetky hodnoty („GrossValue“, „Amount“) musia byť KLADNÉ.

10 / „[10] = PayOut“

PRED dokumentom EndOfDay (uzávierka na konci dňa) musí byť celý zostatok hotovosti nastavený na 0 pomocou PayOut. Je to potrebné, pretože zostatok sa neprenáša do nasledujúceho dňa.

Pozor: Ak v tomto momente nie je uložený žiadny PayOut, bude to mať za následok nahlásenie nesprávnych zostatkov hotovosti do iEKA!

Počas dňa je možné uskutočniť ľubovoľný počet výplat. Zostatok hotovosti sa vždy automaticky upraví.

Všetky hodnoty („GrossValue“, „Amount“) musia byť ZÁPORNÉ.

Príklady JSON payloadov

PayIn:

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

(Release: 1.11.4; Verzia 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šenie / prerušenie transakcií

Každé zrušenie transakcie pred jej dokončením sa musí zaznamenať v Litve. Koncový bod

POST /api/v1/transactions/cancelDocument

slúži na tento účel.

Odovzdaný JSON payload by mal obsahovať

všetky pozície zaznamenané až do momentu zrušenia, avšak
prázdny objekt „Payments“.

Príklad:

(Release: 1.11.4; verzia 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 prerušení transakcie sa musia odoslať do iEKA a musia sa tiež zobraziť v správach (pozri nasledujúcu kapitolu).

Záznam v audítorskom protokole – prerušenie / zrušenie transakcií

Ak sa odošle payload na POST /api/v1/transactions/cancelDocument, služba fiskalizácie RetailForce automaticky vygeneruje záznam v technickom protokole udalostí / technickom denníku („audit log“) typu:

DocumentCancelDocument

Záznam obsahuje súčet (GrossValue) jednotlivých položiek v odoslanom payloade, keďže táto informácia

musí byť odoslaná do iEKA a
tiež uviesť v správe (Z) a
správe (X).

Údaje sa odosielajú do iEKA prostredníctvom dokumentu EndOfDay. Pri zaúčtovaní denného uzávierky sa v odpovedi fiscalResponse Litva vracajú nasledujúce hodnoty:

„DayCanceledReceiptsDocumentsQuantity“ – počet zrušených/neuskutočnených transakcií za deň
„DayCanceledReceiptsDocumentsAmount“ – (hrubá) suma všetkých zrušených/neuskutočnených transakcií

Predaj špeciálneho tovaru

V Litve musí byť predaj určitých tovarov osobitne označený. Tieto predaje sa vykazujú do systému iEKA ako samostatné súčty a sú zahrnuté aj v správach (Správa (X), Správa (Z)).

Tieto takzvané „predaje špeciálneho tovaru“ zahŕňajú nasledujúce skupiny produktov:

Alkohol a
palivo

V RetailForce DOM je možné príslušné položky zodpovedajúcim spôsobom označiť pomocou vlastnosti „ItemTypeClassification“. Skupiny produktov klasifikované v Litve ako „špeciálny tovar“ je možné vyhľadať prostredníctvom „fiscalCountryProperties“ (vlastnosť: „supportedItemTypeClassification“).

Správy

Pokladničné systémy musia byť schopné generovať nasledujúce správy:

Správa (X) – denná priebežná správa (tiež známa ako Správa (X))
Správa (Z) – denná daňová správa (tiež známa ako Správa (Z))
Podrobná daňová správa
Súhrnná finančná správa

Správa	documentType	Poznámky
Správa (X)	98 / „[98] = CashCheck“	možno vygenerovať prostredníctvom koncového bodu GET /api/v1/closing/{clientId}/endofdayDocument, avšak pred odoslaním payloadu (/storeDocument) je potrebné zmeniť nasledujúce údaje: „documentType“ > na 98 resp. „[98] = EndOfDay“ „documentTypeCaption“ > na ľubovoľnú hodnotu; napr. „Správa (X)“ „documentId“ > na ID dokumentu z POS systému „documentNumber“ > na číslo dokumentu z POS systému
Správa (Z)	99 / „[99] = EndOfDay“	možno vygenerovať prostredníctvom koncového bodu GET /api/v1/closing/{clientId}/endofdayDocument. Ako zvyčajne je potrebné upraviť nasledujúce údaje: „DocumentId“ > na ID dokumentu v POS systéme „documentNumber“ > na číslo dokumentu v POS systéme
Podrobná daňová správa	-	V RetailForce neexistuje žiadny explicitný typ dokumentu („documentType“) pre podrobnú daňovú správu. Túto správu je možné vygenerovať prostredníctvom nasledujúcich koncových bodov (ľubovoľného z nich): GET /api/v1/management/lithuania/{clientId}/fiscal-report-detail/{reportIdFrom}/{reportIdTo} GET /api/v1/management/lithuania/{clientId}/fiscal-report-date-detail Údaje obsiahnuté v odpovedi slúžia ako základ pre vytvorenie správy v tlačenej forme. Poznámka: Pri volaní jedného z týchto dvoch koncových bodov sa správa vygeneruje a vráti sa do POS systému ako odpoveď. Po volaní je správa už odoslaná do iEKA. Nie sú potrebné žiadne ďalšie kroky.
Súhrnná daňová správa	-	V RetailForce neexistuje žiadny explicitný typ dokumentu („documentType“) pre súhrnnú daňovú správu. Túto správu je možné vygenerovať prostredníctvom nasledujúcich koncových bodov (ľubovoľné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 obsiahnuté v odpovedi slúžia ako základ pre vytvorenie správy v tlačenej forme. Poznámka: Po volaní jedného z týchto dvoch koncových bodov sa správa vygeneruje a vráti sa do POS systému ako odpoveď. Po volaní je správa už odoslaná do iEKA. Nie sú potrebné žiadne ďalšie kroky.

Ďalšie informácie o tom, aké údaje musia byť zahrnuté v príslušných správach, nájdete v článku Požiadavky na dokumenty v Litve.

EKJ

Tento článok bol preložený automaticky.

Špecifické charakteristiky Litva v skratke

Predpoklady

Service company

Bezpečnostný modul

Parameter service company

Bezpečnostný modul

Digitálne certifikáty

Aktualizácia je potrebná

Hodnoty bezpečnostného modulu

Obnovenie testovacieho bezpečnostného modulu

Komunikácia s iEKA

Odstraňovanie chýb

Postup

Stav transakcie

Špeciálne procesy

Vrátenie / výmena tovaru

Technický denník

Súčty v správach

PayIn a výbery

Príklady JSON payloadov

Zrušenie / prerušenie transakcií

Záznam v audítorskom protokole – prerušenie / zrušenie transakcií

Predaj špeciálneho tovaru

Správy

EKJ

Príspevky

Predpoklady

Service company

Bezpečnostný modul

Parameter service company

Bezpečnostný modul

Digitálne certifikáty

Aktualizácia je potrebná

Hodnoty bezpečnostného modulu

Obnovenie testovacieho bezpečnostného modulu

Komunikácia s iEKA

Odstraňovanie chýb

Postup

Stav transakcie

Špeciálne procesy

Vrátenie / výmena tovaru

Technický denník

Súčty v správach

PayIn a výbery

Príklady JSON payloadov

Zrušenie / prerušenie transakcií

Záznam v audítorskom protokole – prerušenie / zrušenie transakcií

Predaj špeciálneho tovaru

Správy

EKJ

Podobné články