Mantenha-se atualizado sobre as novidades de cada módulo do sistema Tron disponibilizadas na primeira semana de Janeiro de 2026.
Módulo Escrita Fiscal Versão 14.0.29
► Melhoria:
Reforma Tributária
A Tron Informática está liderando a adaptação tecnológica à maior reforma tributária das últimas décadas. Este projeto não é apenas uma atualização de sistema; é a fundação de um novo modelo fiscal para o Brasil, preparando nossas soluções para a plena implementação da Reforma Tributária do Consumo (RTC).
Este desenvolvimento coloca nossos clientes à frente da conformidade, garantindo que suas operações com NF-e e NFC-e estejam prontas para os novos tributos CBS (Contribuição sobre Bens e Serviços) e IBS (Imposto sobre Bens e Serviços).
Nova Estrutura de Menus e Processos
Melhoria: Criação de uma aba dedicada "Tributação Sobre Consumo - RTC" no sistema, com módulos específicos para Entrada, Saída e Auditoria de documentos fiscais.
- Gestão Completa dos Novos Tributos : Telas especializadas para o lançamento e controle de CBS e IBS, incluindo todos os campos exigidos pelo novo leiaute da NF-e (tags do XML).
- Suporte a regimes especiais: Monofásico, Crédito Presumido, Compras Governamentais, Diferimento, Retenção e Ajustes.
- Precisão e Controle Total : Grids de produtos com visibilidade completa da base de cálculo, alíquotas evalores de CBS/IBS por item.
- Cadastro e validação de Classificações Tributárias (cClassTrib), Códigos de Situação Tributária (CST) e Códigos de Crédito Presumido (cCredPres) conforme anexos da lei.
- Futuro-Proof : Estrutura preparada para a futura implementação do Imposto Seletivo (IS), aguardando apenas a publicação das tabelas oficiais.
Importação de documentos
Melhoria: Foi desenvolvida uma funcionalidade automatizada para cálculo e preenchimento do crédito presumido de ICMS de 20% no registro D197 da EFD ICMS/IPI, destinada a empresas de transporte interestadual no estado de São Paulo. O sistema agora realiza todo o processo de forma inteligente e parametrizável, garantindo conformidade com o Convênio ICMS 106/96 e o RICMS/SP.
O que foi feito?
- Cálculo Automático: O sistema calcula automaticamente 20% do valor do ICMS devido em cada CT-e ou BP-e (a partir de julho/2023).
- Parâmetro Configurável: Foi adicionado um check “Crédito Presumido de Transporte – SP” no cadastro fiscal da empresa. A opção só é visível e editável para empresas de SP, permitindo ativar/desativar o cálculo conforme a necessidade.
- Geração Inteligente do Registro D197: Se o check estiver ativado e o registro D197 não existir no arquivo importado, o sistema calcula e preenche automaticamente. Se o check estiver desativado ou o registro já existir no arquivo, o sistema mantém os dados originais (cópia fiel).
- Preenchimento de Observações: Quando não houver observações nos documentos, o sistema insere automaticamente a fundamentação legal: *“Convênio ICMS 106/96 e o artigo 11 do Anexo III do RICMS/SP”*.
- Validação e Logs: Caso o código de ajuste SP10090311 não esteja cadastrado, o sistema gera um log detalhado para orientar o usuário
Geração de Informações Oficiais > SPED Fiscal
Melhoria: Foram implementadas importantes atualizações no leiaute do EFD-ICMS/IPI para garantir conformidade com as exigências legais a partir de janeiro de 2026. As melhorias incluem a nova versão 020 do arquivo e a inclusão de campos obrigatórios que refletem mudanças na legislação, assegurando que o sistema esteja sempre alinhado com as normas do SPED Fiscal.
O que foi feito?
- Versão 020 do EFD-ICMS/IPI : A versão 020 foi disponibilizada na tela de geração do arquivo para períodos a partir de 01/2026.
- Novo Campo Obrigatório no Registro 1310 : Foi adicionado o campo “Capacidade de Armazenagem”. O campo é numérico, com tamanho 006 e obrigatório para meses/anos a partir de 01/2026.
- Inclusão da DUIMP no Registro C120 : Foi acrescentada a opção “2 – Declaração Única de Importação (DUIMP)” na listagem de documentos de importação. Disponível apenas para períodos a partir de 01/2026, atualizando o sistema conforme as mudanças na fiscalização aduaneira.
Geração de Informações Oficiais > SPED PIS/COFINS
Melhoria: Foi adicionada a versão 006 na tela de geração do arquivo EFD-Contribuições (PIS/COFINS) para o ano de 2026, mantendo as mesmas regras e consistência da geração do ano anterior. Essa atualização garante que o sistema esteja alinhado com as exigências legais mais recentes desde o primeiro dia do novo exercício fiscal.
► Ajustes:
Cadastros > Condôminos
Ajustes: O Problema:
Em um determinado cenário, foram identificados vários condôminos com o campo “Inscrição (CPF/CNPJ)” vazio e, em alguns casos, com o tipo de inscrição incorreto. Como o campo é obrigatório no cadastro, essa inconsistência impedia a geração de relatórios importantes, como a Declaração de Quitação Condominial, que dependem desses dados para emissão correta.
A Solução:
Foi ajustada a lógica de validação e habilitação dos campos no cadastro de condôminos. Anteriormente, os campos de inscrição eram desabilitados após o salvamento inicial, impedindo correções posteriores. Agora, os campos permanecem habilitados quando a inscrição não está preenchida, permitindo que o usuário insira ou corrija a informação a qualquer momento. A correção também atende a casos de cadastros originados por importação de planilha, garantindo que a inscrição possa ser inserida mesmo em registros importados sem esse dado.
Cadastros > Síndicos
Ajustes: O Problema:
Ao cadastrar um síndico no sistema Laris, ocorria um erro sempre que o campo “Percentual de Isenção do Síndico” era preenchido durante o cadastro inicial. O comportamento inconsistente obrigava o usuário a deixar o campo em branco no primeiro momento, salvar o cadastro e só depois editá-lo para inserir o percentual — um processo pouco intuitivo e que gerava retrabalho.
A Solução:
O problema foi identificado no frontend: o valor do campo “Percentual de Isenção” era enviado ao backend em um tipo de dado incompatível (número), quando o sistema esperava uma string. A correção consistiu em aplicar um método ao valor antes do envio, garantindo que a formatação e o tipo de dado fossem aceitoscorretamente pelo backend.
Integração > Arquivo Remessa
Ajustes: O Problema:
Durante a validação do arquivo de remessa gerado para o banco Sicoob, foi identificado que a data da multa estava sendo gerada igual à data de vencimento. Essa situação viola o padrão CNAB240, que exige que a multa seja aplicada apenas após o vencimento.
A Solução:
Foi implementada uma correção lógica no método responsável pelo cálculo das datas, adicionando uma validação para garantir que a data da multa seja sempre posterior à data de vencimento. A alteração foi aplicada tanto no fluxo de geração do arquivo quanto no campo do portador, assegurando conformidade com o layout CNAB240.
Integração > Retorno Bancário
Ajustes: O Problema:
Ao tentar importar arquivos de retorno bancário da instituição Ailos (Viacredi), o sistema identificava corretamente os boletos, mas exibia a mensagem de erro “85 não foi implementado”. Isso impedia a conclusão da importação e a atualização automática do status das cobranças.
A Solução:
O problema estava na forma como os códigos de ocorrência do retorno eram tratados entre frontend e backend. A correção envolveu: Ajuste nas descrições dos códigos de ocorrência no backend. Remoção da lógica de exibição direta do código no frontend. Implementação de um regex no frontend para exibir apenas a mensagem correspondente ao código de ocorrência, sem expor detalhes técnicos ao usuário.
Relatórios Financeiros > Acordo
Ajustes: O Problema:
Um cliente relatou que ao tentar emitir relatórios de acordos financeiros no sistema Laris, selecionando a data específica, o sistema retornava a mensagem “Não foram encontrados acordos!”, mesmo existindo acordos registrados para aquela unidade e período. O problema ocorria apenas quando a data inicial informada era igual à data do acordo. Se a data inicial fosse anterior, o sistema conseguia localizar os registros.
A Solução:
Identificou-se que o frontend enviava as datas em formato incorreto para o backend (DD/MM/AAAA), causando falha na consulta. A correção padronizou o envio das datas no formato ISO (AAAA-MM-DD), permitindo que o sistema interprete corretamente o intervalo informado.
Relatórios Financeiros > Relação de Boletos Gerados
Ajustes: O Problema:
Ao gerar o relatório “Relação de Boletos Gerados” em PDF, foi observada uma falha de formatação nas colunas de datas, especialmente em “Vencimento Original”, “Último Vencimento” e “Data de Pagamento”. O último dígito do ano aparecia quebrado para a linha seguinte, comprometendo a legibilidade e a apresentação clara do documento.
A Solução:
Ajustado o layout do PDF, com o redimensionamento de colunas, alteração de fontes e espaçamento, para garantir que as datas sejam exibidas completamente em uma única linha.
Relatórios Financeiros > Relação de Recebimentos dos Condôminos
Ajustes: O Problema:
Ao gerar o relatório financeiro “Relação de Recebimentos dos Condôminos” em PDF, foram identificadas várias falhas de formatação que prejudicavam a legibilidade e a apresentação profissional do documento: Colunas muito estreitas, cortando datas e nomes; Quebra de texto em campos como “DATA LANC” e nomes de condôminos; Espaçamento desproporcional entre colunas, especialmente na “UND”; Dificuldade de leitura e interpretação dos dados por parte dos usuários.
A Solução:
Foram realizados ajustes no layout do relatório, com foco na redefinição do tamanho e posicionamento das colunas, além de correções no alinhamento, padding e fontes utilizadas. As alterações visaram distribuir melhor o espaço entre os campos, evitar cortes indesejados e garantir que todos os dados fossem exibidos em uma única linha, melhorando significativamente a clareza visual.
Relatórios Gerenciais > Faturas Enviadas por Email
Ajustes: O Problema:
Ao enviar faturas por e-mail para todas as unidades, o relatório de “Faturas Enviadas por Email” listava menos condôminos que deveria O cliente confirmou que todos os destinatários haviam recebido as faturas, indicando uma inconsistência na geração do relatório, que não refletia a realidade do envio.
A Solução:
Identificou-se que o banco de dados estava registrando os envios antes que o processo de entrega fosse realmente concluído, causando a discrepância nos relatórios.