W niniejszym artykule opisano szczególne kwestie, które należy uwzględnić w kontekście litewskiej fiskalizacji lub które wynikają z przepisów prawnych i wymagań technicznych. Przegląd terminów użytych w niniejszym artykule oraz ich znaczeń można znaleźć w artykule „Terminy związane z litewską fiskalizacją”.

Przegląd treści:

• Warunki wstępne – co jest wymagane do zgodnego z przepisami działania kasy fiskalnej?
• Moduł bezpieczeństwa – czym jest i jakie szczególne funkcje się z nim wiążą?
• Komunikacja z systemem iEKA – co należy wziąć pod uwagę?
• Procesy specjalne – jakie są szczególne cechy:
  • Zwroty/wymiany
  • Dziennik techniczny
  • Sumy w raportach
  • Wpłaty i wypłaty
  • Anulowanie transakcji
  • Sprzedaż towarów specjalnych
• Raporty – jakie raporty należy generować i jakie dane muszą one zawierać?
• EKJ – czym jest i jakie są wymagania?

Warunki wstępne

Aby kasę fiskalną można było uruchomić na Litwie, wymagane są następujące elementy:

Service company

Tylko przedstawiciele certyfikowanej service company mogą dokonywać uruchomienia kas fiskalnych oraz podłączać je do usługi iEKA i modułu bezpieczeństwa.

Firmę serwisową można zdefiniować w konfiguracji dla Litwy. Aby można było wybrać firmę serwisową (dostępną jako pozycja w menu rozwijanym w konfiguracji), wymagana jest umowa między distributorem a firmą serwisową. Po zapisaniu/aktywowaniu umowy w RetailForce portalu w konfiguracji pojawia się pozycja dotycząca firmy serwisowej.

Moduł zabezpieczający

Każda kasa fiskalna musi być wyposażona w certyfikowany moduł bezpieczeństwa. Moduł bezpieczeństwa jest powiązany z service company jedynie w niewielkim stopniu. Jednak przy zakupie modułu bezpieczeństwa prosimy upewnić się, że jest on również obsługiwany przez RetailForce system.

Do zadań modułu bezpieczeństwa należy podpisywanie danych transakcyjnych, zarządzanie licznikiem sumy całkowitej oraz bezpieczne przechowywanie kluczy prywatnych i publicznych oraz certyfikatów cyfrowych.

Parametr „Service company”

Po wybraniu service company w konfiguracji i przypisaniu jej do podmiotu (organizacji, firmy, sklepu, terminala) pracownik tej service company może wprowadzić parametry service company (patrz: Warunki litowskiej fiskalizacji) dla każdego terminala.

Jeśli kasa posiada moduł zabezpieczający, a parametry service company zostały wprowadzone, kasę (urządzenie client) można uruchomić.

Moduł zabezpieczający

Dane z transakcji fiskalnych są automatycznie podpisywane przez usługę fiskalizacji RetailForce za pośrednictwem modułu bezpieczeństwa.

Moduł bezpieczeństwa jest aktywowany automatycznie podczas inicjalizacji. W trakcie tego procesu do modułu bezpieczeństwa wczytywane są również niezbędne certyfikaty cyfrowe.

Certyfikaty cyfrowe

Certyfikaty wykorzystywane do podpisywania danych oraz w innych celach należy odnowić przed upływem ich ważności.

W celu wymiany certyfikatów usługa fiskalizacji udostępnia następującą funkcję:

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

Po wywołaniu tego punktu końcowego usługa fiskalizacji (middleware) sprawdza, czy certyfikaty wymagają wymiany. Jeśli okres ważności certyfikatu dobiega końca, zostaje on zastąpiony nowszym.

Konieczna aktualizacja

Wymiana certyfikatów jest możliwa wyłącznie po zamknięciu dziennym/raportowaniu (Z) (dokument EndOfDay). Dla każdego dokumentu EndOfDay w odpowiedzi fiscalResponse zwracana jest właściwość „certificatesUpdateRequired”.

Jeśli wartość „certificatesUpdateRequired” wynosi „true”, system nadrzędny musi zainicjować wymianę certyfikatu za pomocą punktu końcowego POST /api/v1/management/lithuania/{clientId}/certificate-update.

Wartości modułu bezpieczeństwa

Wartości przechowywane w module bezpieczeństwa (licznik sprzedaży, ID kasy fiskalnej, liczba podpisanych dokumentów i inne) można odczytać za pomocą punktu końcowego

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

Resetowanie modułu bezpieczeństwa testowego

W odróżnieniu od modułów bezpieczeństwa przeznaczonych do pracy produkcyjnej moduły bezpieczeństwa testowe można zresetować do ustawień fabrycznych. Ma to szczególne znaczenie na etapie wdrażania, jeśli wystąpiły błędy (np. w komunikacji z iEKA – patrz poniżej).

Resetowanie przeprowadza się za pomocą punktu końcowego

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

Komunikacja z iEKA 

Oprócz podpisywania danych transakcyjnych za pośrednictwem modułu bezpieczeństwa jednym z kluczowych wymogów litewskiej fiskalizacji jest przekazywanie danych do systemu internetowego organów podatkowych (iEKA).

RetailForce system obsługuje automatyczną komunikację z iEKA. iEKA ogranicza liczbę rekordów danych, które mogą zostać przesłane w określonym przedziale czasowym, a także częstotliwość przesyłania/wysyłania żądań w danym okresie. Z tego powodu usługa fiskalizacji nie przesyła danych do iEKA w czasie rzeczywistym, lecz asynchronicznie.

Debugowanie

Dane wykorzystywane jako podstawa do transmisji są przechowywane przez usługę fiskalizacji w folderze (np. w systemach Windows) C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles.

Proces

Opisany powyżej folder zawiera zazwyczaj trzy podkatalogi:

• send – dane przeznaczone do przesłania do iEKA (dane, które nie zostały jeszcze przesłane).
• accepted – dane, które zostały wysłane do iEKA i zostały zaakceptowane przez system.
• 20xy – odpowiedź z iEKA po weryfikacji danych dla każdego pojedynczego rekordu (oznacza rok, w którym zarejestrowano transakcję)

Przesyłanie danych do iEKA przebiega zgodnie z następującym procesem:

1. RetailForce Client odbiera dane z systemu nadrzędnego („kasa fiskalna”) i
2. konwertuje je do formatu iEKA (w postaci pliku JSON).
3. Ten plik JSON jest przechowywany w folderze \\lithuaniaFiscalFiles\send.
4. Pliki znajdujące się w folderze \\send są okresowo (asynchronicznie) przesyłane do serwisu iEKA. Przed transmisją pliki JSON są konwertowane do formatu XML iEKA.
5. Po dotarciu danych do systemu iEKA, iEKA potwierdza ich odbiór.
6. W tym momencie dane transakcji są przenoszone z folderu \\send do folderu \\accepted wraz z potwierdzeniem otrzymanym od iEKA.
   1. Jeśli dane nie mogły zostać przesłane do iEKA, pozostają one w folderze \\send, a usługa fiskalizacji podejmuje próbę ich przesłania w późniejszym terminie.
7. System iEKA dokonuje teraz walidacji przesłanych danych. Status walidacji musi być aktywnie sprawdzany przez moduł przesyłania danych (usługę fiskalizacji)
8. Zapytanie to jest również wysyłane okresowo ze względu na ograniczenia komunikacyjne po stronie iEKA (patrz wyżej).
9. Wynik zapytania o status weryfikacji jest zapisywany w folderze 20xy (dane są przenoszone z folderu \\accepted do folderu \\20xy).

Status transakcji

Systemy nadrzędne („kasy fiskalne”) mogą sprawdzić status poszczególnych transakcji za pomocą następujących funkcji:

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

Procedury specjalne

Zwroty / wymiany towarów

Zwroty (np. wymiana towarów) są na Litwie traktowane jako dokumenty niefiskalne, tj. transakcje niefiskalne. Są one przesyłane do systemu iEKA, ale nie są podpisywane za pośrednictwem modułu bezpieczeństwa. Oznacza to również, że dokumenty zwrotne nie mają wpływu na liczniki sprzedaży (sumę całkowitą) modułu bezpieczeństwa.

Aby RetailForce system prawidłowo rozpoznawał zwroty jako takie, należy ustawić następujące właściwości:

• „documentType”: 0 / „[0] = Paragon”
• „cancellationDocument”: true
• „documentReference” – należy ustawić odniesienie do innego dokumentu (oryginalnego dokumentu sprzedaży)
• Ujemne hodnoty transakcí („GrossValue”, „NetValue”, „TaxValue”, „Amount”)

Dziennik techniczny

W Litwie należy rejestrować procesy techniczne. Podobnie jak w innych krajach odbywa się to za pomocą dziennika zdarzeń technicznych / dziennika technicznego lub AuditLog.

W szczególności należy rejestrować następujące zdarzenia:

• Otwarcie szuflady kasowej (DrawerOpen) – musi zostać przekazane przez system nadrzędny.
• Unieważnienie dokumentu (DocumentCancelDocument) – jest rejestrowane automatycznie.

Więcej szczegółów można znaleźć w artykule „Zdarzenia techniczne na Litwie”.

Sumy w raportach

W raportach (raport (Z) – dzienny raport fiskalny, raport (X) – dzienny raport okresowy) niektóre sumy (ogólne) muszą być wykazane oddzielnie. Aby to zapewnić, podczas przesyłania danych między systemem źródłowym („kasy fiskalne”) a serwisem fiskalnym należy przestrzegać określonych zasad.

Szczegółowe informacje można znaleźć w artykule „Sumowanie w raportach – Litwa”.

PayIn i wypłaty

Litewskie przepisy dotyczące fiskalizacji wymagają, aby saldo gotówkowe w kasie (szufladzie) było przekazywane do systemu iEKA. Aby to zapewnić, transakcje wpłat i wypłat (np. wpłaty reszty) muszą być również przekazywane z systemu nadrzędnego do usługi fiskalizacji RetailForce (middleware) w postaci dokumentów PayIn i PayOut („documentType”: 11 / „[11] = PayIn” oraz „documentType”: 10 / „[10] = PayOut” z „BusinessTransactionType”: „[90] = MoneyTransfer”).

W odniesieniu do dokumentów PayIn i PayOut należy zwrócić uwagę na następujące kwestie:

Przykłady JSON payloadów

PayIn:

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

Wypłata:

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

Przerwanie / rezygnacja z transakcji

Każde przerwanie transakcji przed jej zakończeniem musi zostać zarejestrowane na Litwie. Punkt końcowy

• POST /api/v1/transactions/cancelDocument

służy do tego celu.

Przesyłany JSON payload powinien zawierać

• wszystkie pozycje zarejestrowane do momentu rezygnacji, ale
• pusty obiekt „Payments”.

Przykład:

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

Dane dotyczące przerwania transakcji muszą zostać przesłane do iEKA, a także uwzględnione w raportach (patrz następny rozdział).

Wpis w dzienniku audytowym dotyczący przerwania / porzucenia transakcji

W przypadku wysłania payload do POST /api/v1/transactions/cancelDocument usługa fiskalizacji RetailForce automatycznie generuje wpis w technicznym dzienniku zdarzeń / dzienniku technicznym („dzienniku audytowym”) typu:

• DocumentCancelDocument

Wpis zawiera sumę (GrossValue) poszczególnych pozycji w przesłanym payloadu, ponieważ informacja ta

• musi zostać przekazana do iEKA i
• również uwzględniona w raporcie (Z) oraz
• w raporcie (X).

Dane są przekazywane do iEKA za pośrednictwem dokumentu EndOfDay. Po zaksięgowaniu zamknięcia dziennego w odpowiedzi fiscalResponse Lithuania zwracane są następujące wartości:

• „DayCanceledReceiptsDocumentsQuantity” – liczba przerwanych / odrzuconych transakcji w ciągu dnia
• „DayCanceledReceiptsDocumentsAmount” – suma (brutto) wszystkich przerwanych / odrzuconych transakcji

Sprzedaż towarów specjalnych

Na Litwie sprzedaż niektórych towarów musi być wyraźnie oznaczona. Sprzedaż ta jest zgłaszana do systemu iEKA jako odrębne sumy i jest również uwzględniana w raportach (Raport (X), Raport (Z)).

Tak zwana „sprzedaż towarów specjalnych” obejmuje następujące grupy produktów:

• Alkohol oraz
• paliwo

W systemie RetailForce DOM odpowiednie pozycje można odpowiednio oznaczyć za pomocą właściwości „ItemTypeClassification”. Grupy produktów sklasyfikowane na Litwie jako „towary specjalne” można wyszukiwać za pomocą właściwości „fiscalCountryProperties” (właściwość: „supportedItemTypeClassification”).

Raporty

Systemy kasowe muszą umożliwiać generowanie następujących raportów:

• Raport (X) – dzienny raport okresowy (znany również jako Raport (X))
• Raport (Z) – dzienny raport fiskalny (znany również jako Raport (Z))
• Szczegółowe sprawozdanie fiskalne
• Podsumowujące sprawozdanie rozliczeniowe

Więcej informacji na temat danych, które muszą zostać uwzględnione w poszczególnych raportach, można znaleźć w artykule „Wymagania dotyczące dokumentów na Litwie”.

EKJ

Niniejszy artykuł został przetłumaczony automatycznie.