Ta članek opisuje posebne značilnosti, ki jih je treba upoštevati v okviru litovske fiskalizacije ali ki izhajajo iz zakonodaje in tehničnih zahtev. Pregled izrazov, uporabljenih v tem članku, in njihovih pomenov najdete v članku Izrazi litovske fiskalizacije.

Pregled vsebine:

• Predpogoji – kaj je potrebno za skladno delovanje blagajne?
• Varnostni modul – kaj je to in katere posebne funkcije so z njim povezane?
• Komunikacija iEKA – kaj je treba upoštevati?
• Posebni postopki – kakšne so posebnosti:
  • Vrnitve/zamenjave
  • Tehnični dnevnik
  • Seštevki v poročilih
  • Vplačila in izplačila
  • Preklic transakcije
  • Prodaja posebnega blaga
• Poročila – katera poročila je treba pripraviti in katere podatke morajo vsebovati?
• EKJ – kaj je to in kakšne so zahteve?

Pogoji

Da se lahko blagajna začne uporabljati v Litvi, je potrebno naslednje:

Service company

Blagajne lahko vključijo v obratovanje in jih priključijo na storitev iEKA ter varnostni modul le predstavniki certificirane service company.

Service company can be defined in the settings for Lithuania. For selecting a service company, a contract between the distributor and the service company is required (available as a drop-down element in the settings). Once the contract is saved/activated in the RetailForce portal, a record for the service company is available in the settings.

Varnostni modul

Vsaka blagajna mora biti opremljena s certificiranim varnostnim modulom. Varnostni modul je le posredno povezan s service company. Pri nakupu varnostnega modula pa se prepričajte, da ga podpira tudi RetailForce system.

Naloge varnostnega modula vključujejo podpisovanje podatkov o transakcijah, upravljanje števca skupnega zneska ter varno shranjevanje zasebnih in javnih ključev ter digitalnih certifikatov.

Parameter service company

Ko je v konfiguraciji izbrana service company in dodeljena subjektu (organizaciji, podjetju, trgovini, terminalu), lahko zaposleni v service company za vsak terminal vnese parametre service company (glej Pogoje litovske fiskalizacije).

Če ima blagajna varnostni modul in so bili vneseni parametri service company, se blagajna (client) lahko začne uporabljati.

Varnostni modul

Podatki iz fiskalnih transakcij se prek varnostnega modula samodejno podpisujejo s pomočjo storitve fiskalizacije RetailForce.

Varnostni modul se samodejno aktivira med inicializacijo. Med tem postopkom se v varnostni modul naložijo tudi potrebna digitalna potrdila.

Digitalni certifikati

Potrdila, ki se uporabljajo za podpisovanje podatkov in druge namene, je treba obnoviti, preden potečejo.

Za zamenjavo certifikatov storitev fiskalizacije ponuja naslednjo funkcijo:

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

Ob klicu končne točke storitev fiskalizacije (middleware) preveri, ali je treba certifikate zamenjati. Če se veljavnost certifikata bliža koncu, se ta zamenja z novejšim.

Posodobitev je potrebna

Zamenjava certifikata je mogoča šele po dnevnem zaključku/poročilu (Z) (dokument EndOfDay). Za vsak dokument EndOfDay se v odgovoru fiscalResponse vrne lastnost »certificatesUpdateRequired«.

Če je vrednost »certificatesUpdateRequired« = true, mora nadrejeni sistem sprožiti zamenjavo certifikata prek končne točke POST /api/v1/management/lithuania/{clientId}/certificate-update.

Vrednosti varnostnega modula

Vrednosti, shranjene v varnostnem modulu (prodajni števec, ID blagajne, število podpisanih dokumentov in drugo), je mogoče prebrati prek končne točke

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

Ponastavitev testnega varnostnega modula

Za razliko od varnostnih modulov za dejansko delovanje je mogoče testne varnostne module ponastaviti na tovarniške nastavitve. To je še posebej pomembno v fazi implementacije, če so se pojavile napake (npr. v komunikaciji z iEKA – glej spodaj).

Ponastavitev se izvede prek končne točke

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

Komunikacija z iEKA 

Poleg podpisovanja podatkov o transakcijah prek varnostnega modula je prenos podatkov v spletni sistem davčnih organov (iEKA) ena od ključnih zahtev litovske fiskalizacije.

The RetailForce system handles 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. As a result, the data processing service does not transmit data to iEKA in real time, but rather async.

Odpravljanje napak

Podatke, ki se uporabljajo kot podlaga za prenos podatkov, storitev fiskalizacije shranjuje v mapi (npr. v sistemih Windows) C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles.

Postopek

Zgoraj opisana mapa običajno vsebuje tri podmapo:

• send – podatki, ki jih je treba prenesti v iEKA (podatki, ki še niso bili preneseni).
• accepted – podatki, ki so bili poslani v iEKA in jih je sistem sprejel.
• 20xy – odgovor iz iEKA po preverjanju veljavnosti podatkov za vsak posamezen zapis (predstavlja leto, v katerem je bila transakcija evidentirana)

Prenos podatkov v iEKA poteka po naslednjem postopku:

1. RetailForce Client prejme podatke iz zgornjega sistema („blagajna“) in
2. jih pretvori v format iEKA (v obliki datoteke JSON).
3. Ta datoteka JSON se shrani v mapo \\lithuaniaFiscalFiles\send.
4. Datoteke v mapi \\send se redno (asinhrono) prenašajo v storitev iEKA. Pred prenosom se datoteke JSON pretvorijo v XML-format iEKA.
5. Ko podatki prispejo v sistem iEKA, iEKA potrdi prejem.
6. V tem trenutku se podatki o transakcijah skupaj s potrdilom, prejetim od iEKA, premaknejo iz mape \\send v mapo \\accepted.
   1. Če podatkov ni bilo mogoče prenesti v iEKA, ostanejo v mapi \\send, storitev fiskalizacije pa poskuša prenos izvesti kasneje.
7. Sistem iEKA zdaj preveri veljavnost prenesenih podatkov. Modul za prenos podatkov (storitev fiskalizacije) mora aktivno poizvedovati o statusu preverjanja.
8. To poizvedovanje se izvaja tudi periodično zaradi komunikacijskih omejitev s strani iEKA (glej zgoraj).
9. Rezultat poizvedbe o statusu preverjanja se shrani v mapo 20xy (podatki se premaknejo iz mape \\accepted v mapo \\20xy).

Stanje transakcije

Nadrejeni sistemi („blagajne“) lahko preverijo stanje posameznih transakcij z naslednjimi funkcijami:

• GET /api/v1/management/lithuania/{clientId}/check-document-status-by-iEKA-document-number/{iEKADocumentNumber} in
• GET /api/v1/management/lithuania/{clientId}/check-document-status-by-document-number/{DocumentNumber}

Posebni postopki

Vrnitve / zamenjave blaga

Vrnitve (npr. zamenjava blaga) se v Litvi štejejo za nefiskalne dokumente, tj. nefiskalne transakcije. Posredujejo se v sistem iEKA, vendar se ne podpisujejo prek varnostnega modula. To pomeni tudi, da dokumenti o vrnitvah ne vplivajo na števce prodaje (skupni znesek) varnostnega modula.

Da bi sistem RetailForce pravilno prepoznal vračila kot taka, je treba nastaviti naslednje lastnosti:

• »documentType«: 0 / »[0] = Potrdilo«
• »cancellationDocument«: true
• »documentReference« – treba je nastaviti sklic na drug dokument (izvirni prodajni dokument)
• Negativne vrednosti transakcij („GrossValue“, „NetValue“, „TaxValue“, „Amount“)

Tehnični dnevnik

Tehnične procese je treba v Litvi beležiti. Tako kot v drugih državah se to izvaja s pomočjo dnevnika tehničnih dogodkov / tehničnega dnevnika ali AuditLog.

Zlasti je treba zabeležiti naslednje dogodke:

• Odpiranje blagajne (DrawerOpen) – mora ga posredovati nadrejeni sistem.
• Preklic dokumenta (DocumentCancelDocument) – se evidentira samodejno.

Za več podrobnosti glejte članek Tehnični dogodki v Litvi.

Seštevki v poročilih

V poročilih (poročilo (Z) – dnevno fiskalno poročilo, poročilo (X) – dnevno vmesno poročilo) morajo biti določeni (skupni) seštevki prikazani ločeno. Da se to zagotovi, je treba pri prenosu podatkov med izvorni sistem („blagajne“) in fiskalno službo upoštevati določena pravila.

Za podrobnosti glejte članek Seštevanje v poročilih Litva.

PayIn in izplačila

Litovska fiskalizacija zahteva, da se stanje gotovine v blagajni (predalu) prenese v sistem iEKA. Da bi to zagotovili, je treba tudi transakcije vplačil in izplačil (npr. vplačila drobiža) prenesti iz zgornjega sistema v fiskalizacijsko storitev RetailForce (middleware) v obliki dokumentov PayIn in PayOut („documentType“: 11 / »[11] = PayIn« in »documentType«: 10 / »[10] = PayOut« z »BusinessTransactionType«: »[90] = MoneyTransfer«).

Pri PayIn in PayOuts je treba upoštevati naslednje:

Primeri JSON payload-jev

PayIn:

(Release: 1.11.4; različica 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; različica 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": {}
}

Prekinitev / opustitev transakcij

Vsako opustitev transakcije pred njenim zaključkom je treba zabeležiti v Litvi. Končna točka

• POST /api/v1/transactions/cancelDocument

se uporablja za ta namen.

Posredovani JSON payload mora vsebovati

• vse pozicije, zabeležene do trenutka prekinitve, vendar
• prazni objekt »Payments«.

Primer:

(Release: 1.11.4; različica 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": {}
}

Podatki o opustitvi transakcije morajo biti poslani v iEKA in prikazani tudi v poročilih (glej naslednje poglavje).

Vnos v revizijski dnevnik: prekinitev / opustitev transakcij

Če se pošlje payload na POST /api/v1/transactions/cancelDocument, storitev fiskalizacije RetailForce samodejno ustvari vnos v dnevniku tehničnih dogodkov / tehničnem dnevniku („revizijski dnevnik“) naslednjega tipa:

• DocumentCancelDocument

Vnos vsebuje skupno vrednost (GrossValue) posameznih postavk v poslanem payloadu, saj je treba te informacije

• mora biti posredovana iEKA in
• prav tako navedena v poročilu (Z) ter
• poročilu (X).

Podatki se posredujejo v iEKA prek dokumenta EndOfDay. Ob knjiženju dnevnega zaključka se v odgovoru fiscalResponse Lithuania vrnejo naslednje vrednosti:

• »DayCanceledReceiptsDocumentsQuantity« – število prekinjenih/opuščenih transakcij na dan
• »DayCanceledReceiptsDocumentsAmount« – (bruto) skupni znesek vseh prekinjenih / opuščenih transakcij

Prodaja posebnega blaga

V Litvi mora biti prodaja določenega blaga posebej označena. Te prodaje se v sistemu iEKA poročajo kot ločeni seštevki in so vključene tudi v poročila (Poročilo (X), Poročilo (Z)).

Te tako imenovane »prodaje posebnega blaga« obsegajo naslednje skupine izdelkov:

• Alkohol in
• gorivo

V RetailForce DOM se lahko ustrezne postavke ustrezno označijo z lastnostjo »ItemTypeClassification«. Skupine izdelkov, ki so v Litvi razvrščene kot »posebno blago«, se lahko poiščejo prek »fiscalCountryProperties« (lastnost: »supportedItemTypeClassification«).

Poročila

Blagajniški sistemi morajo biti sposobni ustvarjati naslednja poročila:

• Poročilo (X) – dnevno vmesno poročilo (znano tudi kot Poročilo (X))
• Poročilo (Z) – dnevno fiskalno poročilo (znano tudi kot Poročilo (Z))
• Podrobno fiskalno poročilo
• Povzetek zaključnega poročila

Za več informacij o tem, katere podatke je treba vključiti v posamezna poročila, si oglejte članek Zahteve glede dokumentov v Litvi.

EKJ

Ta članek je bil samodejno preveden.