Acest articol descrie caracteristicile speciale care trebuie luate în considerare în contextul fiscalizării din Lituania sau care decurg din legislație și din cerințele tehnice. O prezentare generală a termenilor utilizați în acest articol și a semnificațiilor acestora poate fi găsită în articolul Termeni ai fiscalizării din Lituania.

Prezentare generală a conținutului:

• Condiții prealabile – ce este necesar pentru funcționarea conformă a casei de marcat?
• Modulul de securitate – ce este acesta și ce funcții speciale îi sunt asociate?
• Comunicarea iEKA – ce trebuie luat în considerare?
• Procese speciale – care sunt caracteristicile speciale ale:
  • Retururi/schimburi
  • Jurnalul tehnic
  • Totaluri în rapoarte
  • Depuneri și retrageri
  • Anularea tranzacțiilor
  • Vânzarea de mărfuri speciale
• Rapoarte – ce rapoarte trebuie generate și ce date trebuie să conțină acestea?
• EKJ – ce este și care sunt cerințele?

Condiții preliminare

Pentru ca o casă de marcat să poată fi pusă în funcțiune în Lituania, sunt necesare următoarele:

Service company

Numai reprezentanții unei service companies certificate pot pune în funcțiune casele de marcat și le pot conecta la serviciul iEKA și la modulul de securitate.

Puteți defini o service company prin configurația Lituania. Pentru a selecta o service company, este necesar un contract între distribuitor și service company (disponibil ca element din meniul derulant din configurație). Odată ce contractul a fost stocat/activat în RetailForce portal, o intrare pentru service company este disponibilă în configurație.

Modulul de securitate

Fiecare casă de marcat trebuie să fie echipată cu un modul de securitate certificat. Modulul de securitate are doar o legătură indirectă cu service company-ul. Cu toate acestea, atunci când achiziționați un modul de securitate, vă rugăm să vă asigurați că acesta este compatibil cu RetailForce system-ul.

Printre sarcinile modulului de securitate se numără semnarea datelor tranzacțiilor, gestionarea contorului de total general și stocarea în siguranță a cheilor private și publice, precum și a certificatelor digitale.

Parametrul „Service company”

Odată ce o service company a fost selectată în configurație și atribuită unei entități (organizație, companie, magazin, terminal), un angajat al service company poate introduce parametrii service company (a se vedea Termenii fiscalizării din Lituania) pentru fiecare terminal.

Dacă casa de marcat dispune de un modul de securitate și au fost introduși parametrii service company-ului, casa de marcat (clientul) poate fi pusă în funcțiune.

Modulul de securitate

Datele din tranzacțiile fiscale sunt semnate automat de serviciul de fiscalizare RetailForce prin intermediul modulului de securitate.

Modulul de securitate se activează automat în timpul inițializării. În cadrul acestui proces, certificatele digitale necesare sunt, de asemenea, încărcate în modulul de securitate.

Certificate digitale

Certificatele utilizate pentru semnarea datelor și în alte scopuri trebuie reînnoite înainte de expirare.

Pentru schimbul de certificate, serviciul de fiscalizare pune la dispoziție funcția:

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

Atunci când se apelează punctul final, serviciul de fiscalizare (middleware) verifică dacă certificatele trebuie înlocuite. Dacă un certificat se apropie de sfârșitul perioadei de valabilitate, acesta este înlocuit cu unul mai nou.

Actualizare necesară

Schimbul de certificate este posibil numai după închiderea zilnică/raportul (Z) (documentul EndOfDay). Pentru fiecare document EndOfDay, proprietatea „certificatesUpdateRequired” este returnată în fiscalResponse.

Dacă valoarea „certificatesUpdateRequired” = true, sistemul din amonte trebuie să inițieze o schimbare a certificatului utilizând punctul de capăt POST /api/v1/management/lithuania/{clientId}/certificate-update.

Valori modul de securitate

Valorile stocate în modulul de securitate (contor de vânzări, ID-ul casei de marcat, numărul de documente semnate și altele) pot fi citite utilizând punctul de interfață

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

Resetarea modulului de securitate de testare

Spre deosebire de modulele de securitate pentru funcționarea în condiții reale, modulele de securitate de testare pot fi resetate la setările implicite din fabrică. Acest lucru este deosebit de important în faza de implementare, în cazul în care au apărut erori (de exemplu, în comunicarea cu iEKA – a se vedea mai jos).

Resetarea se efectuează utilizând punctul final

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

Comunicarea cu iEKA 

Pe lângă semnarea datelor tranzacțiilor prin intermediul modulului de securitate, transferul de date către sistemul online al autorităților fiscale (iEKA) este una dintre cerințele cheie ale fiscalizării din Lituania.

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

Depanare

Datele utilizate ca bază pentru transmiterea datelor sunt stocate de serviciul de fiscalizare în folderul (de exemplu, pe sistemele Windows) C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles.

Proces

Dosarul descris mai sus conține, de obicei, trei subdirectoare:

• send – Date care urmează să fie transferate către iEKA (date care nu au fost încă transferate).
• accepted – Date care au fost trimise către iEKA și au fost acceptate de sistem.
• 20xy – Răspunsul primit de la iEKA după validarea datelor pentru fiecare înregistrare de date în parte (reprezintă anul în care a fost înregistrată tranzacția)

Transmiterea datelor către iEKA se desfășoară conform următorului proces:

1. RetailForce Client primește date de la sistemul din amonte („casă de marcat”) și
2. le convertește în formatul iEKA (dar sub forma unui fișier JSON).
3. Acest fișier JSON este stocat în folderul \\lithuaniaFiscalFiles\send.
4. Fișierele din folderul \\send sunt transferate periodic (asincron) către serviciul iEKA. Înainte de transmitere, fișierele JSON sunt convertite în formatul XML al iEKA.
5. Odată ce datele au ajuns în sistemul iEKA, iEKA confirmă primirea.
6. În acest moment, datele tranzacției sunt mutate din folderul \\send în folderul \\accepted, împreună cu confirmarea primită de la iEKA.
   1. Dacă datele nu au putut fi transferate către iEKA, acestea rămân în folderul \\send, iar serviciul de fiscalizare încearcă să le transfere la un moment ulterior.
7. Sistemul iEKA validează acum datele transferate. Starea validării trebuie interogată în mod activ de către modulul de transfer de date (serviciul de fiscalizare)
8. Această interogare se efectuează, de asemenea, periodic, din cauza restricțiilor de comunicare din partea iEKA (a se vedea mai sus).
9. Rezultatul interogării stării de validare este stocat în folderul 20xy (datele sunt mutate din \\accepted în \\20xy).

Starea tranzacției

Sistemele din amonte („casele de marcat”) pot verifica starea tranzacțiilor individuale utilizând următoarele funcții:

• GET /api/v1/management/lithuania/{clientId}/check-document-status-by-iEKA-document-number/{iekaDocumentNumber} și
• GET /api/v1/management/lithuania/{clientId}/check-document-status-by-document-number/{DocumentNumber}

Procese speciale

Retururi / schimburi de mărfuri

Retururile (de exemplu, schimbul de mărfuri) sunt considerate documente nefiscale în Lituania, adică tranzacții nefiscale. Acestea sunt transmise către sistemul iEKA, dar nu sunt semnate prin intermediul modulului de securitate. Acest lucru înseamnă, de asemenea, că documentele de retur nu afectează contoarele de vânzări (totalul general) ale modulului de securitate.

Pentru ca sistemul RetailForce să recunoască corect returnările ca atare, trebuie setate următoarele proprietăți:

• „documentType”: 0 / „[0] = Chitanță”
• „cancellationDocument”: true
• „documentReference” – trebuie setată referința la un alt document (documentul de vânzare original)
• Valori negative ale tranzacțiilor („GrossValue”, „NetValue”, „TaxValue”, „Amount”)

Jurnalul tehnic

Procesele tehnice trebuie înregistrate în Lituania. La fel ca în alte țări, acest lucru se realizează folosind Jurnalul de evenimente tehnice / Jurnalul tehnic sau AuditLog.

În special, trebuie înregistrate următoarele evenimente:

• Deschiderea sertarului de bani (DrawerOpen) – trebuie transmisă de sistemul din amonte.
• Anularea documentului (DocumentCancelDocument) – se înregistrează automat.

Pentru mai multe detalii, consultați articolul Evenimente tehnice Lituania.

Totaluri în rapoarte

În rapoarte (raportul (Z) – raport fiscal zilnic, raportul (X) – raport intermediar zilnic), anumite totaluri (generale) trebuie afișate separat. Pentru a asigura acest lucru, trebuie respectate anumite reguli la transferul datelor între sistemul sursă („casele de marcat”) și serviciul de fiscalizare.

Pentru detalii, consultați articolul „Totalizare în rapoarte – Lituania”.

PayIn și plăți

Fiscalizarea din Lituania impune ca soldul de numerar din casa de marcat (sertar) să fie transmis către iEKA. Pentru a asigura acest lucru, tranzacțiile de încasare și plată (de exemplu, depuneri de rest) trebuie, de asemenea, transmise din sistemul din amonte către serviciul de fiscalizare RetailForce (middleware) sub forma documentelor PayIn și PayOut („documentType”: 11 / „[11] = PayIn” și „documentType”: 10 / „[10] = PayOut” cu „BusinessTransactionType”: „[90] = MoneyTransfer”).

În ceea ce privește plățile de PayIn și de ieșire, trebuie reținut următorul aspect:

Exemple de JSON payload

PayIn:

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

Anularea / abandonarea tranzacțiilor

Orice abandonare a unei tranzacții înainte de finalizarea acesteia trebuie înregistrată în Lituania. Punctul final

• POST /api/v1/transactions/cancelDocument

este utilizat în acest scop.

The transmitted JSON payload must contain

• toate pozițiile înregistrate până la momentul abandonării, dar
• un obiect „Payments” gol.

Exemplu:

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

Datele privind abandonarea tranzacției trebuie trimise către iEKA și, de asemenea, afișate în rapoarte (a se vedea capitolul următor).

Înregistrare în jurnalul de audit privind anularea/abandonarea tranzacțiilor

Dacă se trimite o sarcină utilă la POST /api/v1/transactions/cancelDocument, serviciul de fiscalizare RetailForce generează automat o înregistrare în jurnalul de evenimente tehnice / jurnalul tehnic („jurnal de audit”) de tipul:

• DocumentCancelDocument

Înregistrarea conține valoarea totală (GrossValue) a articolelor individuale din payload-ul transmis, deoarece această informație

• trebuie transmisă către iEKA și
• trebuie, de asemenea, inclusă în raportul (Z) și
• raportul (X).

Datele sunt transmise către iEKA prin intermediul documentului EndOfDay. Atunci când se înregistrează o închidere zilnică, în fiscalResponse Lituania sunt returnate următoarele valori:

• „DayCanceledReceiptsDocumentsQuantity” – numărul de tranzacții anulate/abandonate pe zi
• „DayCanceledReceiptsDocumentsAmount” – valoarea totală (brută) a tuturor tranzacțiilor anulate/abandonate

Vânzarea de bunuri speciale

În Lituania, vânzarea anumitor bunuri trebuie să fie etichetată în mod specific. Aceste vânzări sunt raportate către sistemul iEKA ca totaluri separate și sunt, de asemenea, incluse în rapoarte (Raportul (X), Raportul (Z)).

Aceste așa-numite „Vânzări de bunuri speciale” cuprind următoarele grupe de produse:

• Alcool și
• combustibil

În RetailForce DOM, articolele relevante pot fi marcate corespunzător folosind proprietatea „ItemTypeClassification”. Grupurile de produse clasificate ca „mărfuri speciale” în Lituania pot fi interogate prin intermediul „fiscalCountryProperties” (proprietate: „supportedItemTypeClassification”).

Rapoarte

Sistemele de casă de marcat trebuie să poată genera următoarele rapoarte:

• Raportul (X) – raportul intermediar zilnic (cunoscut și sub denumirea de Raportul (X))
• Raportul (Z) – raport fiscal zilnic (cunoscut și sub denumirea de Raportul (Z))
• Raport fiscal detaliat
• Raport fiscal sumar

Pentru mai multe informații privind datele care trebuie incluse în rapoartele respective, vă rugăm să consultați articolul Cerințe privind documentele în Lituania.

EKJ

Acest articol a fost tradus automat.