Овај чланак описује посебне карактеристике које се морају узети у обзир у контексту литванске фискализације, или које произлазе из закона и техничких захтева. Преглед појмова коришћених у овом чланку и њихових значења може се наћи у чланку Термини литванске фискализације.

Преглед садржаја:

• Предуслови – шта је потребно за рад усаглашене касе?
• Безбедносни модул – шта је то и које посебне функције су повезане са њим?
• iEKA комуникација – шта треба узети у обзир?
• Посебни процеси – које су посебне карактеристике:
  • Враћање/замена
  • Технички журнал
  • Збирови у извештајима
  • Уплате и исплате
  • Отказивање трансакције
  • Продаја специјалне робе
• Извештаји – који извештаји морају бити генерисани и које податке морају да садрже?
• EKJ – шта је то и који су захтеви?

Предуслови

Да би се каса ставила у рад у Литванији, потребно је следеће:

Сервисна компанија

Само представници сертификоване сервисне компаније могу пустити у рад касе и повезати их са сервисом iEKA и безбедносним модулом.

Можете дефинисати сервисну компанију преко конфигурације Литванија. Потребан је уговор између дистрибутера и сервисне компаније да би сервисна компанија била доступна за избор (доступна као падајући елемент у конфигурацији). Када је уговор сачуван/активиран на порталу RetailForce, унос за сервисну компанију је доступан у конфигурацији.

Безбедносни модул

Свака каса мора бити опремљена сертификованим безбедносним модулом. Безбедносни модул је само лабаво повезан са сервисном компанијом. Међутим, приликом куповине безбедносног модула, уверите се да га такође подржава RetailForce систем.

Задатке безбедносног модула чине потписивање података о трансакцији, управљање бројачем укупног промета и безбедно чување приватних и јавних кључева и дигиталних сертификата.

Параметар сервисне компаније

Када се у конфигурацији изабере сервисна компанија и додели ентитету (организацији, компанији, продавници, терминалу), запослени у сервисној компанији може унети параметре сервисне компаније (погледајте Услове литванске фискализације) за сваки терминал.

Ако каса има безбедносни модул и унети су параметри сервисне компаније, каса (клијент) може да се пусти у рад.

Безбедносни модул

Подаци из фискалних трансакција се аутоматски потписују преко фискализационе услуге RetailForce путем безбедносног модула.

Безбедносни модул се аутоматски активира током иницијализације. Током овог процеса у безбедносни модул се такође учитавају потребни дигитални сертификати.

Дигитални сертификати

Сертификати који се користе за потписивање података и у друге сврхе морају бити обновљени пре истека рока важења.

За размену сертификата, сервис фискализације обезбеђује функцију:

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

Када се позове крајња тачка, услуга фискализације (мидлвејр) проверава да ли је потребно заменити сертификате. Ако сертификат приступа крају свог рока важења, он се замењује новим.

Ажурирање неопходно

Размена сертификата је могућа само након дневног затварања/извештаја (Z) (документ EndOfDay). За сваки документ EndOfDay, својство "certificatesUpdateRequired" се враћа у fiscalResponse.

Ако је вредност "certificatesUpdateRequired" = true, горњи систем мора да покрене размену сертификата користећи крајњу тачку POST /api/v1/management/lithuania/{clientId}/certificate-update.

Вредности безбедносног модула

Вредности сачуване у безбедносном модулу (бројач продаја, ИД касе, број потписаних докумената и друге) могу се прочитати коришћењем крајње тачке

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

Ресетовање тест-безбедносног модула

За разлику од безбедносних модула за рад уживо, тест безбедносне модуле је могуће ресетовати на фабричка подешавања. Ово је посебно важно током фазе имплементације ако су се појавиле грешке (нпр. у комуникацији са iEKA – видети у наставку).

Ресетовање се врши преко ендпоинта

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

iEKA комуникација 

Поред потписивања података о трансакцији преко безбедносног модула, пренос података у онлајн систем пореских органа (iEKA) један је од кључних захтева литванске фискализације.

Систем RetailForce води аутоматску комуникацију са iEKA. iEKA ограничава број записа података који се могу пренети у одређеном временском периоду, као и учесталост трансфера/захтева у том периоду. Из тог разлога, услуга фискализације не преноси податке ка iEKA у реалном времену, већ асинхроно.

Отклањање грешака

Подаци који се користе као основа за пренос података чувају се у сервису за фискализацију у фасцикли (нпр. на Windows системима) C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles.

Процес

Горе описана фасцикла обично садржи три поддиректоријума:

• send - Подаци који се преносе на iEKA (подаци који још нису пренети).
• accepted - Подаци који су послати iEKA и које је систем прихватио.
• 20xy - Одговор од iEKA након валидације података за сваки појединачни запис (представља годину у којој је трансакција евидентирана)

Пренос података ка iEKA пролази кроз следећи процес:

1. RetailForce Client прима податке из горњег система ("касе") и
2. претвара га у iEKA формат (али као JSON фајл).
3. Ова JSON датотека се чува у фасцикли \\lithuaniaFiscalFiles\send.
4. Датотеке у фасцикли \\send периодично (асинхроно) се преносе на iEKA сервис. Пре преноса, JSON датотеке се конвертују у iEKA XML формат.
5. Када подаци стигну у iEKA систем, iEKA потврђује пријем.
6. У том тренутку подаци о трансакцији се премештају из фасцикле \\send у фасциклу \\accepted, заједно са потврдом примљеном од iEKA.
   1. Ако подаци нису могли да буду пренети у iEKA, они остају у фасцикли \\send и сервис за фискализацију покушава да их пренесе у неком каснијем тренутку.
7. Систем iEKA сада валидира пренесене податке. Статус валидације мора активно да се упита преко модула за пренос података (услуга фискализације).
8. Овај упит се такође извршава периодично због ограничења у комуникацији са стране iEKA (види горе).
9. Резултат упита о статусу валидације се чува у фолдеру 20xy (подаци се премештају из \\accepted у \\20xy).

Статус трансакције

Горњи системи ("касе") могу проверити статус појединачних трансакција користећи следеће функције:

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

Посебни процеси

Враћање / замена робе

Враћања (нпр. замена робе) се у Литванији сматрају нефискалним документима, тј. нефискалним трансакцијама. Они се преносе у iEKA систем, али се не потписују преко безбедносног модула. Ово такође значи да документи о враћању не утичу на бројила продаје (укупно) безбедносног модула.

Да би систем RetailForce исправно препознао повраћаје као такве, морају бити подешене следеће особине:

• "documentType": 0 / "[0] = Receipt"
• "cancellationDocument": true
• "documentReference" - референца на други документ (оригинални документ о продаји) мора бити подешена
• Негативне вредности трансакције ("GrossValue", "NetValue", "TaxValue", "Amount")

Технички дневник

Технички процеси морају бити евидентирани у Литванији. Као и у другим земљама, ово се ради коришћењем Техничког дневника догађаја / Техничког дневника или AuditLog-а.

Посебно морају бити евидентирани следећи догађаји:

• Отварање фиоке за новац (DrawerOpen) – мора да буде пренето од стране извора података.
• Отказ документа (DocumentCancelDocument) – бележи се аутоматски.

За више детаља погледајте чланак Technical Events Lithuania.

Збирови у извештајима

У извештајима (извештај (Z) – дневни фискални извештај, извештај (X) – дневни међуизвештај), одређени (укупни) тотали морају бити приказани одвојено. Да би се то обезбедило, морају се поштовати одређена правила при преносу података између изворног система ("фискалних каси" ) и сервиса за фискализацију.

За детаље погледајте чланак Збирање у извештајима Литванија.

Уплата и исплата

Литванска фискализација захтева да се стање готовине у фискалној каси (фиоци) пренесе у iEKA. Да би се то обезбедило, трансакције уплате и исплате (нпр. депозити за кусур) такође морају бити пренете из изворног система у RetailForce сервис за фискализацију (middleware) у облику PayIn и PayOut докумената ("documentType": 11 / "[11] = PayIn" и "documentType": 10 / "[10] = PayOut" са "businessTransactionType": "[90] = MoneyTransfer").

За PayIn и PayOut треба имати у виду следеће:

Примери JSON оптерећења

Уплата:

(Издање: 1.11.4; 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": {}
}

Исплата:

(Издање: 1.11.4; 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": {}
}

Прекид / Напуштање трансакција

Сваки прекид трансакције пре њеног завршетка мора бити евидентиран у Литванији. Крајња тачка

• POST /api/v1/transactions/cancelDocument

се користи у ту сврху.

Пренесени JSON садржај треба да садржи

• све позиције евидентиране до тренутка напуштања, али
• празан објекат "Payments".

Пример:

(Издање: 1.11.4; 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": {}
}

Подаци о напуштању трансакције морају бити послати iEKA и такође приказани у извештајима (погледајте следеће поглавље).

Упис у аудиторски лог о прекиду / напуштању трансакција

Ако се пошаље payload на POST /api/v1/transactions/cancelDocument, сервис фискализације RetailForce аутоматски генерише унос у технички дневник догађаја / технички журнал ("audit log") следећег типа:

• DocumentCancelDocument

Унос садржи укупан износ (GrossValue) појединачних ставки у пренесеном плунгу, јер су ове информације

• мора да се пренесе iEKA и
• такође пријављено у извештају (Z) и
• извештај (X).

Подаци се преносе iEKA путем документа EndOfDay. Када се пошаље дневно затварање, у FiscalResponse Lithuania се враћају следеће вредности:

• "DayCanceledReceiptsDocumentsQuantity" - број отказивања/напуштања трансакција по дану
• "DayCanceledReceiptsDocumentsAmount" - (бруто) укупан износ свих отказаних трансакција / напуштања

Продаја посебне робе

У Литванији, продаја одређене робе мора бити посебно означена. Ове продаје се пријављују систему iEKA као засебни укупни износи и такође се укључују у извештаје (Извештај (X), Извештај (Z)).

Ове такозване "Продаје посебне робе" обухватају следеће групе производа:

• Алkohol и
• Гориво

У RetailForce DOM, релевантни артикли могу бити одговарајуће означени помоћу својства "itemTypeClassification". Групе производа класификоване као "Специјална роба" у Литванији могу се претражити преко "FiscalCountryProperties" (својство: "supportedItemTypeClassification").

Извештаји

Системи касира морају бити у могућности да генеришу следеће извештаје:

• Извештај (X) – дневни прелиминарни извештај (такође познат као Извештај (X))
• Извештај (Z) – дневни фискални извештај (такође познат као Извештај (Z))
• Детаљан фискални извештај
• Резиме фискалног извештаја

За више информација о томе који подаци морају бити укључени у одговарајуће извештаје, погледајте чланак "Document requirements Lithuania".

EKJ

Овај чланак је аутоматски преведен.