В тази статия са описани специфичните особености, които трябва да се вземат предвид в контекста на литовската фискализация или които произтичат от законите и техническите изисквания. Общ преглед на термините, използвани в тази статия, и тяхното значение можете да намерите в статията Термини на литовската фискализация.

Преглед на съдържанието:

• Предпоставки – какво е необходимо за работа на касовия апарат в съответствие с изискванията?
• Модул за сигурност – какво представлява и какви специални функции са свързани с него?
• Комуникация с iEKA – какво трябва да се има предвид?
• Специални процеси – какви са специфичните особености на:
  • Връщане/замяна
  • Технически дневник
  • Общи суми в отчетите
  • Депозити и тегления
  • Анулиране на транзакции
  • Продажба на специални стоки
• Отчети – кои отчети трябва да се изготвят и какви данни трябва да съдържат?
• EKJ – какво представлява и как може да бъде извлечен?

Предпоставки

За да може касовият апарат да бъде пуснат в експлоатация в Литва, са необходими следните условия:

Service company

Само представители на сертифицирана service company могат да пускат касови апарати в експлоатация и да ги свързват с услугата iEKA и модула за сигурност.

Можете да зададете service company чрез конфигурацията Литва. За да може да бъде избрана service company (достъпна като елемент от падащото меню в конфигурацията), е необходим договор между дистрибутора и service company. След като договорът бъде запазен/активиран в RetailForce portal, в конфигурацията се появява запис за service company.

Модул за сигурност

За описания тук модел на фискализация с модул за сигурност касовият апарат трябва да бъде оборудван с модул за сигурност, който отговаря на приложимите литовски изисквания. Литовските правила допускат и касови апарати с виртуална фискализация, които не изискват модул за сигурност (официални указания на VMI). Модулът за сигурност е свързан само косвено със service company. При закупуване на модул за сигурност обаче, моля, уверете се, че той се поддържа и от RetailForce system.

Задачите на модула за сигурност включват подписване на данни за транзакции, управление на брояча на общата сума и сигурно съхранение на частни и публични ключове и цифрови сертификати.

Параметър „Service company“

След като service company е избрана в конфигурацията и е присвоена към даден субект (организация, фирма, магазин, terminal), служител на service company може да въведе параметрите на service company (вижте Условията за фискализация в Литва) за всеки terminal.

Ако касовият апарат разполага с модул за сигурност и са въведени параметрите на service company, касовият апарат (клиентът) може да бъде пуснат в експлоатация.

Модул за сигурност

Данните от фискалните транзакции се подписват автоматично от услугата за фискализация на RetailForce чрез модула за сигурност.

Модулът за сигурност се активира автоматично по време на инициализацията. Необходимите цифрови сертификати също се зареждат в модула за сигурност по време на този процес.

Цифрови сертификати

Сертификатите, използвани за подписване на данни и за други цели, трябва да бъдат подновени преди изтичането на валидността им.

За обмен на сертификати услугата за фискализация предоставя следната функция:

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

Когато се извика крайната точка, услугата за фискализация (middleware) проверява дали сертификатите трябва да бъдат подменени. Ако срокът на валидност на даден сертификат е на път да изтече, той се заменя с по-нов.

Необходимо обновяване

Замяната на сертификат е възможна само след дневно приключване/отчет (Z) (документ EndOfDay). За всеки документ EndOfDay в fiscalResponse се връща свойството „certificatesUpdateRequired“.

Ако стойността на „certificatesUpdateRequired“ е true, системата нагоре по веригата трябва да инициира замяна на сертификат чрез крайната точка POST /api/v1/management/lithuania/{clientId}/certificate-update.

Стойности на модула за сигурност

Стойностите, съхранявани в модула за сигурност (брояч на продажбите, ID на касовия апарат, брой подписани документи и др.), могат да бъдат прочетени чрез крайната точка

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

Възстановяване на фабричните настройки на тестовия модул за сигурност

За разлика от модулите за сигурност за реална експлоатация, тестовите модули за сигурност могат да бъдат възстановени към фабричните настройки по подразбиране. Това е особено важно по време на фазата на внедряване, ако са възникнали грешки (например в комуникацията с iEKA – вижте по-долу).

Възстановяването на фабричните настройки се извършва чрез крайната точка

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

Комуникация с iEKA

Освен подписването на данните за транзакциите чрез модула за сигурност, преносът на данни към онлайн системата на данъчните органи (iEKA) е едно от ключовите изисквания на литовската фискализация.

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. As a result, the fiscalisation service does not transmit data to iEKA in real time, but rather asynchronously.

Отстраняване на грешки

Данните, използвани като основа за предаването на данни, се съхраняват от услугата за фискализация в папката (например в системи с 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 system правилно да разпознава връщанията като такива, трябва да бъдат зададени следните свойства:

• "documentType": 0 / "[0] = Касова бележка"
• "cancellationDocument": true
• "documentReference" – трябва да бъде зададена препратка към друг документ (оригиналният документ за продажба)
• Отрицателни стойности на транзакциите („GrossValue“, „NetValue“, „TaxValue“, „Amount“)

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

Техническите процеси трябва да се записват в Литва. Както и в другите държави, това се извършва чрез Technical Event Log / Technical Journal или „AuditLog“.

По-конкретно трябва да се регистрират следните събития:

• Отваряне на касовото чекмедже (DrawerOpen) – трябва да се предава от предходната система.
• Анулиране на документ (DocumentCancelDocument) – записва се автоматично.

За повече подробности вижте статията Технически събития в Литва.

Общи суми в отчетите

В отчетите (отчет (Z) – дневен фискален отчет, отчет (X) – дневен междинен отчет) определени (общи) суми трябва да се показват отделно. За да се гарантира това, трябва да се спазват определени правила при прехвърлянето на данни между изходната система („касови апарати“) и фискалната служба.

За подробности вижте статията Обобщаване в отчетите – Литва.

PayIn и PayOut

Литовската фискализация изисква салдото на наличността в касовия апарат (касовото чекмедже) да се предава към iEKA. За да се гарантира това, транзакциите за входни и изходни плащания (например депозити на ресто) също трябва да се предават от изходната система към услугата за фискализация RetailForce (middleware) под формата на документи „PayIn“ и „PayOut“ („documentType“: 11 / „[11] = PayIn“ и „documentType“: 10 / „[10] = PayOut“ с „BusinessTransactionType“: „[90] = MoneyTransfer“).

За PayIn и PayOut трябва да се има предвид следното:

Примери за JSON payload

PayIn:

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

PayOut:

(Release: 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 payload трябва да съдържа

• всички позиции, регистрирани до момента на отмяната, но
• празен обект „Payments“.

Пример:

(Release: 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 автоматично генерира запис в техническия дневник на събитията / техническия журнал („аудитен дневник“) от типа:

• DocumentCancelDocument

Записът съдържа общата стойност (GrossValue) на отделните артикули в предаденото payload, тъй като тази информация

• трябва да бъде предадена на iEKA и
• също така трябва да бъде включена в отчета (Z) и
• отчета (X).

Данните се предават към iEKA чрез документа „EndOfDay“. Когато се осчетоводи дневното приключване, в fiscalResponse Lithuania се връщат следните стойности:

• „DayCanceledReceiptsDocumentsQuantity“ – брой прекъснати/отменени транзакции на ден
• „DayCanceledReceiptsDocumentsAmount“ – (брутна) обща сума на всички прекъснати/отменени транзакции

Продажба на специални стоки

В Литва продажбата на определени стоки трябва да бъде специално обозначена. Тези продажби се отчитат в системата iEKA като отделни суми и също се включват в отчетите (Отчет (X), Отчет (Z)).

Така наречените „продажби на специални стоки“ обхващат следните групи продукти:

• Алкохол и
• гориво

В RetailForce DOM съответните артикули могат да бъдат маркирани по подходящ начин чрез свойството „ItemTypeClassification“. Продуктовите групи, класифицирани като „специални стоки“ в Литва, могат да бъдат търсени чрез „fiscalCountryProperties“ (свойство: „supportedItemTypeClassification“).

Отчети

Касовите системи трябва да могат да генерират следните отчети:

• Отчет (X) – дневен междинен отчет (известен също като Отчет (X))
• Отчет (Z) – дневен фискален отчет (известен също като Отчет (Z))
• Подробен фискален отчет
• Обобщен фискален отчет

За повече информация относно данните, които трябва да бъдат включени в съответните отчети, моля, вижте статията Изисквания към документите в Литва.

EKJ

EKJ (електронна контролна лента, вижте Условия за фискализация в Литва) се съхранява автоматично от фискалния клиент. В RetailForce Cloud и в API крайните точки тя се нарича ECJ.

Как се записва EKJ

• След всеки документ, подписан от модула за сигурност (например касова бележка, входящо/изходящо плащане, отчет (X), отчет (Z)), фискалният клиент генерира текстовата версия на документа и я добавя към EKJ файла за текущия ден (един текстов файл на ден).
• Ако клиентът е свързан с RetailForce Cloud, всеки запис се прехвърля и в облачния архив.

Извличане на EKJ

• Fiscal Client: GET /api/v1/management/lithuania/{clientId}/ecj-zip?fromDate={date}&tillDate={date} връща ZIP файл с по един текстов файл за всеки ден от избрания период. Ако няма данни за EKJ за съответния период, се връща грешката „Няма намерени данни.“.
• Портал RetailForce Cloud: на литовски терминал действието „Покажи EKJ“ отваря диалогов прозорец. Изберете „Дата“ и кликнете върху „Покажи“, за да видите EKJ за съответния ден от архива в облака.
• RetailForce Cloud API: GET /api/v1.0/implementation/lt/{terminalId}/ecj?date={date} връща EKJ за един ден (име на файла и съдържание). GET /api/v1.0/implementation/lt/{terminalId}/ecj-zip?fromDate={date}&tillDate={date} стартира експортиране на избрания период като ZIP файл; когато експортирането приключи, файлът може да бъде изтеглен чрез известията в RetailForce Cloud Portal.

Тази статия е преведена автоматично.