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

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

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

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

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

Service company

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

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

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

Всяка касова система трябва да бъде оборудвана със сертифициран модул за сигурност. Модулът за сигурност е свързан само косвено със 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 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 за Литва се връщат следните стойности:

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

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

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

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

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

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

Отчети

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

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

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

EKJ

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