Este artigo descreve as características específicas que devem ser tidas em conta no contexto da fiscalização lituana, ou que decorrem da legislação e dos requisitos técnicos. Pode encontrar uma visão geral dos termos utilizados neste artigo e dos seus significados no artigo «Termos da fiscalização lituana».

Visão geral do índice:

• Pré-requisitos – o que é necessário para o funcionamento conforme da caixa registadora?
• Módulo de segurança – o que é e que funções especiais lhe estão associadas?
• Comunicação iEKA – o que é necessário ter em conta?
• Processos especiais – quais são as características específicas de:
  • Devoluções/trocas
  • Registo técnico
  • Totais nos relatórios
  • Depósitos e levantamentos
  • Anulação de transações
  • Venda de mercadorias especiais
• Relatórios – que relatórios devem ser gerados e que dados devem conter?
• EKJ – o que é e quais são os requisitos?

Requisitos prévios

Para que uma caixa registadora possa ser colocada em funcionamento na Lituânia, é necessário o seguinte:

Service company

Apenas os representantes de uma service company certificada podem colocar as caixas registadoras em funcionamento e ligá-las ao serviço iEKA e ao módulo de segurança.

Pode definir uma service company através da configuração «Lituânia». É necessário um contrato entre o distribuidor e a service company para que esta possa ser selecionada (disponível como opção num menu suspenso na configuração). Assim que o contrato for guardado/ativado no RetailForce portal, fica disponível uma entrada para a service company na configuração.

Módulo de segurança

Cada caixa registadora deve estar equipada com um módulo de segurança certificado. O módulo de segurança está apenas vagamente relacionado com a service company. No entanto, ao adquirir um módulo de segurança, certifique-se de que este também é compatível com o RetailForce system.

As funções do módulo de segurança incluem a assinatura de dados de transações, a gestão do contador do total geral e o armazenamento seguro de chaves privadas e públicas, bem como de certificados digitais.

Parâmetro «Service company»

Depois de uma service company ter sido selecionada na configuração e atribuída a uma entidade (organização, empresa, loja, terminal), um colaborador da service company pode introduzir os parâmetros da service company (ver Termos da fiscalização lituana) para cada terminal.

Se a caixa registadora possuir um módulo de segurança e os parâmetros da service company tiverem sido introduzidos, a caixa registadora (o client) pode ser colocada em funcionamento.

Módulo de segurança

Os dados das transações fiscais são automaticamente assinados pelo serviço de fiscalização da RetailForce através do módulo de segurança.

O módulo de segurança é ativado automaticamente durante a inicialização. Os certificados digitais necessários são também carregados no módulo de segurança durante este processo.

Certificados digitais

Os certificados utilizados para assinar dados e para outros fins devem ser renovados antes de expirarem.

Para substituir os certificados, o serviço de fiscalização disponibiliza a seguinte função:

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

Quando o ponto de extremidade é chamado, o serviço de fiscalização (middleware) verifica se os certificados precisam de ser substituídos. Se um certificado estiver a aproximar-se do fim do seu período de validade, é substituído por um mais recente.

Atualização necessária

A troca de certificados só é possível após um encerramento/relatório diário (Z) (documento EndOfDay). Para cada documento EndOfDay, a propriedade «certificatesUpdateRequired» é devolvida na fiscalResponse.

Se o valor de «certificatesUpdateRequired» for «true», o sistema a montante deve iniciar uma troca de certificados utilizando o ponto de extremidade POST /api/v1/management/lithuania/{clientId}/certificate-update.

Valores do módulo de segurança

Os valores armazenados no módulo de segurança (contador de vendas, ID da caixa registadora, número de documentos assinados e outros) podem ser lidos utilizando o ponto de extremidade

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

Reinicialização do módulo de segurança de teste

Ao contrário dos módulos de segurança para operação em produção, os módulos de segurança de teste podem ser repostos para os valores predefinidos de fábrica. Isto é particularmente importante durante a fase de implementação, caso tenham ocorrido erros (por exemplo, na comunicação iEKA – ver abaixo).

A redefinição é realizada através do ponto de extremidade

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

Comunicação com o iEKA 

Para além da assinatura dos dados das transações através do módulo de segurança, a transferência de dados para o sistema online das autoridades fiscais (iEKA) constitui um dos principais requisitos da fiscalização lituana.

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. For this reason, the fiscalisation service does not transmit data to iEKA in real time, but rather de forma assíncrona.

Depuração

Os dados utilizados como base para a transmissão de dados são armazenados pelo serviço de fiscalização na pasta (por exemplo, em sistemas Windows) C:\ProgramData\RetailForce\Fiscal Webservice\{clientId}\lithuaniaFiscalFiles.

Processo

A pasta acima descrita contém normalmente três subpastas:

• send — Dados a transferir para a iEKA (dados que ainda não foram transferidos).
• accepted - Dados que foram enviados para o iEKA e aceites pelo sistema.
• 20xy - Resposta da iEKA após a validação dos dados para cada registo individual (representa o ano em que a transação foi registada)

A transmissão de dados para o iEKA segue o seguinte processo:

1. O RetailForce client recebe dados do sistema a montante («caixa registadora») e
2. converte-os para o formato iEKA (mas como um ficheiro JSON).
3. Este ficheiro JSON é armazenado na pasta \\lithuaniaFiscalFiles\send.
4. Os ficheiros na pasta \\send são transferidos periodicamente (de forma assíncrona) para o serviço iEKA. Antes da transmissão, os ficheiros JSON são convertidos para o formato XML da iEKA.
5. Assim que os dados chegam ao sistema iEKA, este confirma a receção.
6. Nesta altura, os dados da transação são movidos da pasta \\send para a pasta \\accepted, juntamente com a confirmação recebida do iEKA.
   1. Caso os dados não tenham podido ser transferidos para o iEKA, permanecem na pasta \\send e o serviço de fiscalização tenta transferi-los posteriormente.
7. O sistema iEKA procede agora à validação dos dados transferidos. O estado da validação deve ser ativamente consultado pelo módulo de transferência de dados (serviço de fiscalização)
8. Esta consulta é também efetuada periodicamente devido a restrições de comunicação por parte da iEKA (ver acima).
9. O resultado da consulta do estado de validação é armazenado na pasta 20xy (os dados são movidos de \\accepted para \\20xy).

Estado da transação

Os sistemas a montante («caixas registadoras») podem verificar o estado de transações individuais utilizando as seguintes funções:

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

Processos especiais

Devoluções / trocas de mercadorias

As devoluções (por exemplo, troca de mercadorias) são consideradas documentos não fiscais na Lituânia, ou seja, transações não fiscais. São transmitidas ao sistema iEKA, mas não são assinadas através do módulo de segurança. Isto significa também que os documentos de devolução não afetam os contadores de vendas (total geral) do módulo de segurança.

Para que o RetailForce system reconheça corretamente as devoluções como tal, devem ser definidas as seguintes propriedades:

• «documentType»: 0 / «[0] = Recibo»
• "cancellationDocument": true
• «documentReference» — deve ser definida uma referência a outro documento (o documento de venda original)
• Valores de transação negativos («GrossValue», «NetValue», «TaxValue», «Amount»)

Registo técnico

Os processos técnicos devem ser registados na Lituânia. Tal como noutros países, isto é feito através do Registo de Eventos Técnicos / Diário Técnico ou AuditLog.

Devem ser registados, em particular, os seguintes eventos:

• Abertura da gaveta de dinheiro (DrawerOpen) – deve ser transmitida pelo sistema a montante.
• Anulação de documento (DocumentCancelDocument) – é registada automaticamente.

Para mais detalhes, consulte o artigo «Eventos Técnicos na Lituânia».

Totais nos relatórios

Nos relatórios (relatório (Z) – relatório fiscal diário, relatório (X) – relatório provisório diário), determinados totais (gerais) devem ser apresentados separadamente. Para garantir isso, devem ser respeitadas determinadas regras aquando da transferência de dados entre o sistema de origem («caixas registadoras») e o serviço de fiscalização.

Para mais detalhes, consulte o artigo «Totalização nos relatórios – Lituânia».

PayIn e Saídas

A fiscalização lituana exige que o saldo de caixa na caixa registadora (gaveta) seja transmitido ao iEKA. Para garantir isso, as transações de entrada e saída de dinheiro (por exemplo, depósitos de trocos) também devem ser transmitidas do sistema a montante para o serviço de fiscalização RetailForce (middleware) sob a forma de documentos PayIn e PayOut («documentType»: 11 / «[11] = PayIn» e «documentType»: 10 / «[10] = PayOut» com «BusinessTransactionType»: «[90] = MoneyTransfer»).

É necessário ter em conta o seguinte relativamente aos PayIns e PayOuts:

Exemplos de JSON payloads

PayIn:

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

Anulação / Abandono de transações

Qualquer abandono de uma transação antes da sua conclusão deve ser registado na Lituânia. O ponto final

• POST /api/v1/transactions/cancelDocument

é utilizado para este efeito.

The transmitted JSON payload must contain

• todas as posições registadas até ao momento do abandono, mas
• um objeto «Payments» vazio.

Exemplo:

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

Os dados relativos ao abandono da transação devem ser enviados para a iEKA e também apresentados nos relatórios (consulte o capítulo seguinte).

Entrada no registo de auditoria relativa ao cancelamento/abandono de transações

Se for enviada uma carga útil para POST /api/v1/transactions/cancelDocument, o serviço de fiscalização da RetailForce gera automaticamente uma entrada no registo de eventos técnicos / diário técnico («registo de auditoria») do tipo:

• DocumentCancelDocument

A entrada contém o total (GrossValue) dos itens individuais na payload transmitida, uma vez que esta informação

• deve ser transmitida à iEKA e
• também deve ser incluída no relatório (Z) e
• no relatório (X).

Os dados são transmitidos à iEKA através do documento «EndOfDay». Quando é lançado um fecho diário, são devolvidos os seguintes valores na «fiscalResponse Lithuania»:

• «DayCanceledReceiptsDocumentsQuantity» — número de transações canceladas/abandonadas por dia
• «DayCanceledReceiptsDocumentsAmount» — valor (bruto) total de todas as transações abortadas/abandonadas

Venda de bens especiais

Na Lituânia, a venda de determinados bens deve ser especificamente identificada. Estas vendas são comunicadas ao sistema iEKA como totais separados e são também incluídas nos relatórios (Relatório (X), Relatório (Z)).

Estas chamadas «Vendas de Mercadorias Especiais» abrangem os seguintes grupos de produtos:

• Álcool e
• Combustível

No RetailForce DOM, os artigos relevantes podem ser assinalados em conformidade utilizando a propriedade «ItemTypeClassification». Os grupos de produtos classificados como «Bens Especiais» na Lituânia podem ser consultados através das «fiscalCountryProperties» (propriedade: «supportedItemTypeClassification»).

Relatórios

Os sistemas de caixa registadora devem ser capazes de gerar os seguintes relatórios:

• Relatório (X) – relatório provisório diário (também conhecido como Relatório (X))
• Relatório (Z) – relatório fiscal diário (também conhecido como Relatório (Z))
• Relatório fiscal detalhado
• Relatório fiscal resumido

Para mais informações sobre os dados que devem ser incluídos nos respetivos relatórios, consulte o artigo «Requisitos documentais na Lituânia».

EKJ

Este artigo foi traduzido automaticamente.