Cet article décrit les particularités dont il convient de tenir compte dans le cadre de la fiscalisation lituanienne, ou qui découlent de la législation et des exigences techniques. Vous trouverez un aperçu des termes utilisés dans cet article et de leur signification dans l’article « Termes relatifs à la fiscalisation lituanienne ».

Aperçu du sommaire :

• Conditions préalables – que faut-il pour garantir le fonctionnement conforme d’une caisse enregistreuse ?
• Module de sécurité – de quoi s’agit-il et quelles sont les fonctions spécifiques qui y sont associées ?
• Communication iEKA – quels sont les éléments à prendre en compte ?
• Processus spécifiques – quelles sont les particularités concernant :
  • Retours/échanges
  • Journal technique
  • Totaux dans les rapports
  • Dépôts et retraits
  • Annulation de transaction
  • Vente de marchandises spéciales
• Rapports – quels rapports doivent être générés et quelles données doivent-ils contenir ?
• EKJ – de quoi s’agit-il et quelles sont les exigences ?

Conditions préalables

Pour qu’un système de caisse puisse être mis en service en Lituanie, les conditions suivantes doivent être remplies :

entreprise de maintenance

Seuls les représentants d’une service company certifiée sont habilités à mettre en service des caisses enregistreuses et à les connecter au service iEKA ainsi qu’au module de sécurité.

La société de services peut être définie via la configuration « Lituanie ». Un contrat entre le distributeur et la société de services est nécessaire pour que celle-ci puisse être sélectionnée (disponible sous forme d’élément dans le menu déroulant de la configuration). Une fois le contrat enregistré/activé sur le RetailForce portal, une entrée correspondant à la société de services apparaît dans la configuration.

Module de sécurité

Chaque caisse enregistreuse doit être équipée d’un module de sécurité certifié. Le module de sécurité n’entretient qu’une relation indirecte avec la service company. Toutefois, lors de l’acquisition d’un module de sécurité, veuillez vous assurer qu’il est également pris en charge par le RetailForce system.

Les fonctions du module de sécurité comprennent la signature des données de transaction, la gestion du compteur de total général, ainsi que le stockage sécurisé des clés privées et publiques et des certificats numériques.

Paramètre « Service company »

Une fois qu’une service company a été sélectionnée dans la configuration et affectée à une entité (organisation, entreprise, magasin, terminal), un employé de la service company peut saisir les paramètres de la service company (voir les conditions de fiscalisation lituaniennes) pour chaque terminal.

Si la caisse enregistreuse est équipée d’un module de sécurité et que les paramètres de la service company ont été saisis, la caisse enregistreuse (le client) peut être mise en service.

Module de sécurité

Les données issues des transactions fiscales sont automatiquement signées par le service de fiscalisation RetailForce via le module de sécurité.

Le module de sécurité est activé automatiquement lors de l’initialisation. Les certificats numériques nécessaires sont également chargés dans le module de sécurité au cours de ce processus.

Certificats numériques

Les certificats employés pour la signature des données et à d’autres fins doivent être renouvelés avant leur expiration.

Pour procéder au remplacement des certificats, le service de fiscalisation met à disposition la fonction suivante :

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

Lorsque ce point de terminaison est appelé, le service de fiscalisation (middleware) vérifie si les certificats doivent être remplacés. Si un certificat arrive à la fin de sa période de validité, il est remplacé par un certificat plus récent.

Mise à jour nécessaire

L’échange de certificats n’est possible qu’après une clôture/un rapport quotidien (Z) (document EndOfDay). Pour chaque document EndOfDay, la propriété « certificatesUpdateRequired » est renvoyée dans la réponse fiscalResponse.

Si la valeur de « certificatesUpdateRequired » est égale à true, le système en amont doit lancer un remplacement de certificat à l’aide du point de terminaison POST /api/v1/management/lithuania/{clientId}/certificate-update.

Valeurs du module de sécurité

Les valeurs stockées dans le module de sécurité (compteur de ventes, ID de la caisse enregistreuse, nombre de documents signés, etc.) peuvent être lues à l’aide du point de terminaison

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

Réinitialisation du module de sécurité de test

Contrairement aux modules de sécurité destinés à une exploitation en production, les modules de sécurité de test peuvent être réinitialisés aux paramètres d’usine par défaut. Cela revêt une importance particulière pendant la phase de mise en œuvre si des erreurs se sont produites (par exemple, dans la communication iEKA – voir ci-dessous).

La réinitialisation s’effectue via l’endpoint

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

Communication iEKA 

Outre la signature des données de transaction via le module de sécurité, le transfert de données vers le système en ligne des autorités fiscales (iEKA) constitue l’une des exigences clés de la fiscalisation lituanienne.

Le système RetailForce gère automatiquement la communication avec iEKA. iEKA applique des quotas sur le nombre d’enregistrements transférables durant une période donnée, ainsi que sur la fréquence des transferts/requêtes au cours de cette période. Par conséquent, le service de fiscalisation ne transmet pas les données en temps réel vers iEKA, mais de manière asynchrone.

Débogage

Les données servant de base à la transmission sont stockées par le service de fiscalisation dans le répertoire (par exemple, sur les systèmes Windows) C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles.

Processus

Ce dossier contient généralement trois sous-répertoires :

• send – Données à transférer vers iEKA (données qui n’ont pas encore été transférées).
• accepted – Données qui ont été envoyées à iEKA et acceptées par le système.
• 20xy – Réponse d’iEKA après validation des données pour chaque enregistrement individuel (correspond à l’année au cours de laquelle la transaction a été enregistrée)

La transmission des données vers iEKA suit le processus suivant :

1. RetailForce Client reçoit les données du système en amont (« caisse ») et
2. les convertit au format iEKA (sous forme de fichier JSON).
3. Ce fichier JSON est stocké dans le répertoire \\lithuaniaFiscalFiles\send.
4. Les fichiers du dossier \\send sont transférés périodiquement (de manière asynchrone) vers le service iEKA. Avant la transmission, les fichiers JSON sont convertis au format XML iEKA.
5. Une fois les données parvenues au système iEKA, celui-ci en accuse réception.
6. À ce stade, les données de transaction sont déplacées du dossier \\send vers le dossier \\accepted, accompagnées de l’accusé de réception émis par iEKA.
   1. Si le transfert vers iEKA échoue, les données demeurent dans le dossier \\send et le service de fiscalisation réessaie ultérieurement.
7. Le système iEKA procède ensuite à la validation des données transférées. Le statut de validation doit être activement interrogé par le module de transfert de données (service de fiscalisation)
8. Cette interrogation est également effectuée périodiquement en raison des restrictions de communication imposées par iEKA (voir ci-dessus).
9. Le résultat de l’interrogation du statut de validation est persisté dans le dossier « 20xy » (les données sont déplacées de « \\accepted » vers « \\20xy »).

Statut des transactions

Les systèmes en amont (« caisses enregistreuses ») peuvent vérifier le statut des transactions individuelles à l’aide des fonctions suivantes :

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

Procédures spéciales

Retours / échanges de marchandises

En Lituanie, les retours (par exemple, les échanges de marchandises) sont considérés comme des documents non fiscaux, c’est-à-dire des transactions non fiscales. Ils sont transmis au système iEKA mais ne sont pas signés via le module de sécurité. Cela signifie également que les documents de retour n’ont aucune incidence sur les compteurs de ventes (total général) du module de sécurité.

Afin que le système RetailForce identifie correctement les retours, les propriétés suivantes doivent être configurées :

• « documentType » : 0 / « [0] = Reçu »
• « cancellationDocument » : true
• « documentReference » : la référence à un autre document (le document de vente d’origine) doit être définie
• Valeurs de transaction négatives (« GrossValue », « NetValue », « TaxValue », « Amount »)

Journal technique

Les processus techniques doivent être consignés en Lituanie. Comme dans d’autres pays, cela s’effectue à l’aide du journal des événements techniques / journal technique ou de l’AuditLog.

Les événements suivants doivent notamment être enregistrés :

• Ouverture du tiroir-caisse (DrawerOpen) – doit être transmise par le système en amont.
• Annulation d’un document (DocumentCancelDocument) – est enregistrée automatiquement.

Pour plus de détails, consultez l’article « Événements techniques en Lituanie ».

Totaux dans les rapports

Dans les rapports (rapport (Z) – rapport fiscal quotidien, rapport (X) – rapport intermédiaire quotidien), certains totaux (généraux) doivent être indiqués séparément. Pour ce faire, certaines règles doivent être respectées lors du transfert de données entre le système source (« caisses enregistreuses ») et le service de fiscalisation.

Pour plus de détails, consultez l’article « Totalisation dans les rapports – Lituanie ».

PayIn et décaissements

La fiscalisation lituanienne exige que le solde de caisse de la caisse enregistreuse (tiroir-caisse) soit transmis à l’iEKA. Pour ce faire, les transactions d’encaissement et de décaissement (par exemple, les dépôts de monnaie) doivent également être transmises du système en amont au service de fiscalisation RetailForce (middleware) sous la forme de documents PayIn et PayOut (« documentType » : 11 / « [11] = PayIn » et « documentType » : 10 / « [10] = PayOut » avec « BusinessTransactionType » : « [90] = MoneyTransfer »).

Veuillez noter les points suivants concernant les PayIn et les PayOut :

Exemples de charges JSON

PayIn :

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

Annulation / Abandon de transactions

Tout abandon d’une transaction avant son achèvement doit être enregistré en Lituanie. Le point de terminaison

• POST /api/v1/transactions/cancelDocument

est utilisé à cette fin.

La charge utile JSON transmise doit contenir

• toutes les positions enregistrées jusqu’au moment de l’abandon, mais
• un objet « Payments » vide.

Exemple :

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

Les données relatives à l’abandon d’une transaction doivent être envoyées à iEKA et figurer également dans les rapports (voir le chapitre suivant).

Entrée dans le journal d’audit : interruption / abandon de transactions

Si un payload est envoyé à l’adresse POST /api/v1/transactions/cancelDocument, le service de fiscalisation de RetailForce génère automatiquement une entrée dans le journal des événements techniques (« journal d’audit ») du type :

• DocumentCancelDocument

Cette entrée contient le montant total (GrossValue) des articles individuels figurant dans le payload transmis, car cette information

• doit être transmise à iEKA et
• doit également figurer dans le rapport (Z) et
• le rapport (X).

Les données sont transmises à iEKA via le document EndOfDay. Lorsqu’une clôture journalière est enregistrée, les valeurs suivantes sont renvoyées dans la réponse fiscale (fiscalResponse) pour la Lituanie :

• « DayCanceledReceiptsDocumentsQuantity » — nombre d’annulations / d’abandons de transactions par jour
• « DayCanceledReceiptsDocumentsAmount » : montant (brut) total de toutes les transactions annulées ou abandonnées

Vente de marchandises spéciales

En Lituanie, la vente de certains biens doit faire l’objet d’un étiquetage spécifique. Ces ventes sont déclarées au système iEKA sous forme de totaux distincts et sont également incluses dans les rapports (Rapport (X), Rapport (Z)).

Ces « ventes de produits spéciaux » englobent les groupes de produits suivants :

• Alcool et
• carburant

Dans RetailForce DOM, les articles concernés peuvent être marqués en conséquence à l’aide de la propriété « ItemTypeClassification ». Les groupes de produits classés comme « produits spéciaux » en Lituanie peuvent être consultés via les « fiscalCountryProperties » (propriété : « supportedItemTypeClassification »).

Rapports

Les systèmes de caisse doivent être en mesure de générer les rapports suivants :

• Rapport (X) – rapport intermédiaire quotidien (également appelé « Rapport (X) »)
• Rapport (Z) – rapport fiscal quotidien (également appelé « Rapport (Z) »)
• Rapport fiscal détaillé
• Rapport fiscal récapitulatif

Pour plus d’informations sur les données devant figurer dans les rapports correspondants, veuillez vous reporter à l’article « Exigences relatives aux documents en Lituanie ».

EKJ

Cet article a été traduit automatiquement.