Este artigo descreve 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 como pode ser consultado?

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

Para o modelo de fiscalização por módulo de segurança aqui descrito, uma caixa registadora deve estar equipada com um módulo de segurança que cumpra os requisitos lituanos aplicáveis. A regulamentação lituana também permite caixas registadoras com fiscalização virtual que não requerem um módulo de segurança (orientações oficiais da VMI). 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 dos dados das 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 igualmente 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 fecho/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 endpoint

• 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 observadas 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 à interrupção/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 Produtos 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

O EKJ (fita de controlo eletrónica, ver Termos da fiscalização lituana) é mantido automaticamente pelo Cliente Fiscal. Na RetailForce Cloud e nos pontos de extremidade da API, é designado por ECJ.

Como é gravada a EKJ

• Após cada documento assinado pelo módulo de segurança (por exemplo, recibo, entrada/saída de dinheiro, relatório (X), relatório (Z)), o Cliente Fiscal gera a versão em texto do documento e anexa-a ao ficheiro EKJ do dia em curso (um ficheiro de texto por dia).
• Se o cliente estiver ligado à RetailForce Cloud, cada registo é também transferido para o arquivo na nuvem.

Recuperação do EKJ

• Cliente Fiscal: GET /api/v1/management/lithuania/{clientId}/ecj-zip?fromDate={date}&tillDate={date} devolve um ficheiro ZIP com um ficheiro de texto por dia do período selecionado. Se não existirem dados do EKJ para o período, é devolvida a mensagem de erro «Não foram encontrados dados.».
• RetailForce Cloud Portal: num terminal lituano, a ação «Mostrar ECJ» abre uma caixa de diálogo. Selecione uma «Data» e clique em «Mostrar» para visualizar o EKJ desse dia a partir do arquivo na nuvem.
• RetailForce Cloud API: GET /api/v1.0/implementation/lt/{terminalId}/ecj?date={date} devolve o EKJ de um dia (nome do ficheiro e conteúdo). GET /api/v1.0/implementation/lt/{terminalId}/ecj-zip?fromDate={date}&tillDate={date} inicia uma exportação do período selecionado como um ficheiro ZIP; quando a exportação estiver concluída, poderá ser descarregada através das notificações no RetailForce Cloud Portal.

Este artigo foi traduzido automaticamente.