Este artículo describe las características especiales que deben tenerse en cuenta en el contexto de la fiscalización lituana, o que se derivan de la legislación y los requisitos técnicos. En el artículo «Términos de la fiscalización lituana» se ofrece una visión general de los términos utilizados en este artículo y sus significados.

Resumen del contenido:

• Requisitos previos: ¿qué se necesita para que el funcionamiento de la caja registradora cumpla con la normativa?
• Módulo de seguridad: ¿en qué consiste y qué funciones especiales conlleva?
• Comunicación iEKA: ¿qué aspectos técnicos deben considerarse?
• Procesos especiales: ¿cuáles son las características específicas de:
  • Devoluciones/cambios
  • Registro técnico
  • Totales en los informes
  • Ingresos y retiradas
  • Anulación de transacciones
  • Venta de productos especiales
• Informes: ¿qué informes deben generarse y qué datos deben contener?
• EKJ: ¿qué es y cuáles son los requisitos?

Requisitos previos

Para que un sistema de punto de venta pueda entrar en funcionamiento en Lituania, se requiere lo siguiente:

Empresa de servicio técnico

Solo los representantes de una Service Company certificada pueden poner en servicio las cajas registradoras y conectarlas al servicio iEKA y al módulo de seguridad.

Puede definir una Service Company a través de la configuración de Lituania. Para poder seleccionar una Service Company (disponible como opción en el menú desplegable de la configuración), es necesario que exista un contrato entre el distribuidor y dicha Service Company. Una vez que el contrato se haya guardado o activado en el RetailForce Portal, aparecerá una entrada correspondiente a la Service Company en la configuración.

Módulo de seguridad

Cada caja registradora debe estar equipada con un módulo de seguridad certificado. El módulo de seguridad solo tiene una relación indirecta con la service company. No obstante, al adquirir un módulo de seguridad, asegúrese de que también sea compatible con el RetailForce system.

Las funciones del módulo de seguridad incluyen la firma de los datos de las transacciones, la gestión del contador de totales generales y el almacenamiento seguro de claves privadas y públicas, así como de certificados digitales.

Parámetro «Service company»

Una vez seleccionada una service company en la configuración y asignada a una entidad (organización, empresa, tienda, terminal), un empleado de dicha service company puede introducir los parámetros de la service company (véanse las Condiciones de fiscalización de Lituania) para cada terminal.

Si la caja registradora dispone de un módulo de seguridad y se han introducido los parámetros de la service company, la caja registradora (el client) podrá ponerse en funcionamiento.

Módulo de seguridad

Los datos de las transacciones fiscales son firmados automáticamente por el servicio de fiscalización de RetailForce a través del módulo de seguridad.

El módulo de seguridad se activa automáticamente durante la inicialización. Durante este proceso, también se cargan en el módulo de seguridad los certificados digitales necesarios.

Certificados digitales

Dichos certificados, empleados para la firma de datos y otros fines, deben renovarse antes de su caducidad.

Para gestionar los certificados, el servicio de fiscalización expone el siguiente punto de API:

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

Al invocar el punto final, el servicio de fiscalización (middleware) verifica si es necesario reemplazar los certificados. Si un certificado está próximo a caducar, se sustituye por uno más reciente.

Actualización necesaria

El intercambio de certificados solo es posible tras un cierre diario/informe (Z) (documento EndOfDay). Para cada documento EndOfDay, se devuelve la propiedad «certificatesUpdateRequired» en la fiscalResponse.

Si el valor de «certificatesUpdateRequired» es «true», el sistema de origen debe iniciar un intercambio de certificados mediante el punto final POST /api/v1/management/lithuania/{clientId}/certificate-update.

Valores del módulo de seguridad

Los valores almacenados en el módulo de seguridad (contador de ventas, ID de la caja registradora, número de documentos firmados y otros) pueden leerse mediante el punto final

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

Restablecimiento del módulo de seguridad de prueba

A diferencia de los módulos de seguridad para el funcionamiento en producción, los módulos de seguridad de prueba pueden restablecerse a los valores predeterminados de fábrica. Esto resulta especialmente importante durante la fase de implementación si se han producido errores (por ejemplo, en la comunicación con iEKA; véase más abajo).

El restablecimiento se realiza mediante el punto final

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

Comunicación con iEKA 

Además de la firma de los datos de las transacciones a través del módulo de seguridad, la transferencia de datos al sistema en línea de las autoridades fiscales (iEKA) es uno de los requisitos clave de la fiscalización lituana.

El sistema RetailForce se encarga de la comunicación automática con iEKA. iEKA limita el número de registros que pueden transferirse en un período de tiempo determinado, así como la frecuencia de transferencias o solicitudes en dicho período. Por este motivo, el servicio de fiscalización no transmite los datos a iEKA en tiempo real, sino de forma asíncrona.

Depuración

Los datos que sirven de base para la transmisión son almacenados por el servicio de fiscalización en la carpeta (por ejemplo, en sistemas Windows) C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles.

El proceso

La carpeta descrita anteriormente suele contener tres subdirectorios:

• send: datos que deben transferirse a iEKA (datos que aún no se han transferido).
• accepted: datos que se enviaron a iEKA y fueron aceptados por el sistema.
• 20xy: respuesta de iEKA tras la validación de los datos de cada registro individual (representa el año en el que se registró la transacción).

La transmisión de datos a iEKA sigue el siguiente proceso:

1. RetailForce Client recibe los datos del sistema anterior («caja registradora») y
2. lo convierte al formato de iEKA (pero como archivo JSON).
3. Este archivo JSON se almacena en la carpeta de origen especificada (\\lithuaniaFiscalFiles\send).
4. Los archivos de la carpeta \\send se transfieren periódicamente (de forma asíncrona) al servicio de iEKA. Antes de la transmisión, los archivos JSON se convierten al formato XML de iEKA.
5. Una vez que los datos llegan al sistema iEKA, este emite una confirmación de recepción.
6. En este momento, los datos de la transacción se trasladan de la carpeta \\send a la carpeta \\accepted, junto con la confirmación recibida de iEKA.
   1. Si la transferencia a iEKA falla, los archivos permanecen en la carpeta \\send y el servicio de fiscalización reintenta la transferencia en un intento posterior.
7. A continuación, el sistema de iEKA valida los datos transferidos. El módulo de transferencia de datos (servicio de fiscalización) debe consultar activamente el estado de la validación
8. Esta consulta también se realiza periódicamente debido a las restricciones de comunicación impuestas por iEKA (véase más arriba).
9. El resultado de dicha consulta se almacena en la carpeta «20xy», trasladando los datos de «\\accepted» a «\\20xy».

Estado de la transacción

Los sistemas de origen («cajas registradoras») pueden consultar el estado de las transacciones individuales mediante las siguientes funciones:

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

Procesos especiales

Devoluciones o cambios de mercancías

Las devoluciones (por ejemplo, el cambio de mercancías) se consideran documentos no fiscales en Lituania, es decir, transacciones no fiscales. Se transmiten al sistema iEKA, pero no se firman a través del módulo de seguridad. Esto también significa que los documentos de devolución no afectan a los contadores de ventas (total general) del módulo de seguridad.

Para que el RetailForce system identifique correctamente las devoluciones como tales, deben configurarse las siguientes propiedades:

• «documentType»: 0 / «[0] = Recibo»
• «cancellationDocument»: true
• «documentReference»: debe establecerse una referencia a otro documento (el documento de venta original)
• Valores de transacción negativos («GrossValue», «NetValue», «TaxValue», «Amount»)

Registro técnico

En Lituania deben registrarse los procesos técnicos. Al igual que en otros países, esto se realiza mediante el «Technical Event Log» / «Technical Journal» o el «AuditLog».

En particular, deben registrarse los siguientes eventos:

• Apertura de la caja registradora (DrawerOpen): debe ser transmitida por el sistema anterior.
• Anulación de documento (DocumentCancelDocument): se registra automáticamente.

Para obtener más detalles, consulte el artículo «Eventos técnicos en Lituania».

Totales en los informes

En los informes (informe (Z) —informe fiscal diario— e informe (X) —informe provisional diario—), determinados totales (generales) deben mostrarse por separado. Para garantizarlo, deben respetarse ciertas normas al transferir datos entre el sistema de origen («cajas registradoras») y el servicio de fiscalización.

Para más detalles, consulte el artículo «Totalización en informes: Lituania».

PayIn y pagos

La fiscalización lituana exige que el saldo de caja de la caja registradora (cajón) se transmita a iEKA. Para garantizarlo, las transacciones de ingreso y pago (por ejemplo, los depósitos de cambio) también deben transmitirse desde el sistema de origen al servicio de fiscalización de RetailForce (middleware) en forma de documentos PayIn y PayOut («documentType»: 11 / «[11] = PayIn» y «documentType»: 10 / «[10] = PayOut» con «BusinessTransactionType»: «[90] = MoneyTransfer»).

En relación con los PayIn y PayOut, debe tenerse en cuenta lo siguiente:

Ejemplos de JSON payloads

PayIn:

(Release: 1.11.4; versión 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; Versión 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": {}
}

Cancelación o abandono de transacciones

Cualquier abandono de una transacción antes de su finalización debe registrarse en Lituania. El punto final

• POST /api/v1/transactions/cancelDocument

se utiliza para este fin.

El JSON payload transmitido debe contener

• todas las posiciones registradas hasta el momento del abandono, pero
• un objeto «Payments» vacío.

Ejemplo:

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

Los datos sobre el abandono de la transacción deben enviarse a iEKA y figurar también en los informes (véase el capítulo siguiente).

Entrada en el registro de auditoría: interrupción o abandono de transacciones

Si se envía una carga útil a POST /api/v1/transactions/cancelDocument, el servicio de fiscalización de RetailForce genera automáticamente una entrada en el registro de eventos técnicos / diario técnico («registro de auditoría») del tipo:

• DocumentCancelDocument

La entrada contiene el total (GrossValue) de las partidas individuales del payload transmitido, ya que esta información

• debe transmitirse a iEKA y
• también debe figurar en el informe (Z) y
• el informe (X).

Los datos se transmiten a iEKA mediante el documento EndOfDay. Al contabilizar un cierre diario, la fiscalResponse de Lituania devuelve los siguientes valores:

• «DayCanceledReceiptsDocumentsQuantity»: número de transacciones anuladas o abandonadas en el día
• «DayCanceledReceiptsDocumentsAmount»: importe (bruto) total de todas las transacciones anuladas o abandonadas

Venta de productos especiales

En Lituania, la venta de determinados productos debe indicarse específicamente. Estas ventas se comunican al sistema iEKA como totales independientes y también se incluyen en los informes (Informe (X), Informe (Z)).

Estas denominadas «ventas de productos especiales» comprenden los siguientes grupos de productos:

• Alcohol y
• combustibles

En RetailForce DOM, los artículos correspondientes pueden marcarse adecuadamente mediante la propiedad «ItemTypeClassification». Los grupos de productos clasificados como «productos especiales» en Lituania pueden consultarse a través de «fiscalCountryProperties» (propiedad: «supportedItemTypeClassification»).

Informes

Los sistemas de caja registradora deben poder generar los siguientes informes:

• Informe (X): informe provisional diario (también conocido como Informe (X))
• Informe (Z): informe fiscal diario (también conocido como Informe (Z))
• Informe fiscal detallado
• Informe fiscal resumido

Para obtener más información sobre los datos que deben incluirse en los respectivos informes, consulte el artículo «Requisitos de documentación en Lituania».

EKJ

Este artículo ha sido traducido automáticamente.