ProblemaNão era possível realizar o pagamento das guias emitidas pelo TaxPlus GNRE. O código de barras era impresso em um formato não aceito pelos leitores das instituições bancárias, e os dígitos de conferência da linha digitável eram calculados por uma regra incorreta, resultando em valores diferentes dos retornados pela SEFAZ.
CorreçãoAjustado o layout de impressão da guia e o cálculo dos dígitos de conferência da linha digitável, incluindo a atualização de banco de dados necessária. A correção foi validada comparando o resultado com o XML e o PDF retornados pela SEFAZ, confirmando que o código de barras passou a ser lido corretamente.
TXPDE-7970Inclusão HOTFIX: 08/09/2026Correção
Correção no código do município
ProblemaCom o parâmetro "Apurar o DIFAL a partir da UF de Entrega" habilitado no add-on GNRe, a UF favorecida era preenchida corretamente, porém o código do município não era preenchido de acordo com essa UF, ocasionando rejeições nas guias enviadas ao WebService.
CorreçãoA guia GNRe passou a considerar também o município do endereço de entrega, não apenas a UF. O código do município correspondente é buscado, convertido para o código oficial do IBGE e gravado corretamente, garantindo o cálculo correto do DIFAL considerando o local exato de entrega da mercadoria.
Implementar o Manual de Integração do Contribuinte - versão 2.16
Implementado(a) o suporte à versão 2.16 do Manual de Integração do Contribuinte da GNRE, que institui um controle de limite de requisições (rate limiting) no web service do Portal GNRE, passando a limitar as chamadas a 500 requisições por minuto por IP. Requisições que excederem esse limite podem ser recusadas temporariamente com o código HTTP 429 – Too Many Requests.
TXPDE-7992Inclusão HOTFIX: 28/08/2026Correção
Problemas nas informações complementares do DAGNRE
ProblemaAo exportar o DAGNRE da Guia em Lote, a chave de acesso do documento estava sendo cortada na parte inferior do arquivo, comprometendo a visualização completa da informação. O comportamento ocorria quando a UF utiliza o campo "Doc. Origem" como chave de acesso nas informações complementares do DAGNRE.
CorreçãoFoi adicionado um componente que mantém a resolução da guia sempre em escala 100%, independentemente da resolução do monitor do usuário, corrigindo o corte da chave de acesso e demais informações complementares do DAGNRE.
TXPDE-7880Inclusão HOTFIX: 19/08/2026Correção
Correção da visualização e exportação do PDF da guia
ProblemaAo tentar visualizar ou exportar o PDF da guia da GNRE, o sistema apresentava um erro no layout de impressão, que impedia a geração do documento (falha na formatação de CPF/CNPJ alfanumérico).
CorreçãoO layout padrão da guia foi ajustado para que a formatação de CPF/CNPJ alfanumérico funcione corretamente em todas as situações, permitindo a visualização e exportação normal do PDF.
TXPDE-7824Inclusão HOTFIX: 10/08/2026Correção
PDF gerado sem código de barras
ProblemaAo autorizar uma guia GNRE, o PDF era gerado sem o código de barras e sem as informações de pagamento, pois o XML de retorno do WebService da UF não era devolvido, impedindo o salvamento no diretório. Além disso, o número de controle da guia era gravado incorretamente no banco, e o processamento manual do arquivo de retorno parava na primeira guia rejeitada, deixando as demais sem finalizar.
CorreçãoO sistema passou a reconsultar automaticamente as guias autorizadas sem retorno da UF, em até 5 tentativas com intervalo entre elas, e o histórico agora exibe a mensagem "Falha na comunicação com o serviço da UF" quando os dados da guia não são devolvidos. Foi corrigida a gravação do número de controle da guia e o travamento no processamento manual do arquivo de retorno. Também foi adicionado um indicador de carregamento durante a criação da guia, e a emissão foi otimizada para consultar o banco uma única vez por lote de notas, eliminando o travamento inicial da tela.
TXPDE-7794Inclusão HOTFIX: 06/08/2026Correção
Erro: "A cota máxima de tamanho de mensagens de entrada foi excedida. Para aumentar a cota, use a propriedade MaxReceivedMessageSize no elemento de associação apropriado."
ProblemaAo autorizar a guia da GNRe, era exibido o erro "A cota máxima de tamanho de mensagens de entrada (65536) foi excedida. Para aumentar a cota, use a propriedade MaxReceivedMessageSize no elemento de associação apropriado.", pois o limite padrão de mensagem no comunicador da SEFAZ era de 65536 bytes (64 KB), e respostas maiores da SEFAZ/GNRe ultrapassavam esse limite, gerando falha na comunicação.
CorreçãoAjustadas as propriedades MaxReceivedMessageSize e MaxBufferSize para 50000000 (aproximadamente 50 MB), seguindo o mesmo padrão já utilizado na NF-e para o tipo de binding HTTPS.
Implementado suporte ao CNPJ alfanumérico no GNRE. Durante os testes com dados reais de CNPJ alfanumérico, foi identificado que a guia GNRE estava sendo gerada considerando apenas a parte numérica do CNPJ do destinatário, desconsiderando os caracteres alfanuméricos. O campo foi ajustado para preencher o CNPJ do destinatário integralmente, preservando letras e números conforme informado no documento fiscal.
Problema no preenchimento do protocolo quando o documento é reconsultado
ProblemaAo autorizar um MDF-e e, posteriormente, realizar a reconsulta do documento, o add-on MDF-e não preenchia corretamente a coluna Protocolo no histórico do documento, impactando diretamente a geração dos eventos de cancelamento e encerramento, que dependem dessa informação.
CorreçãoO MDF-e perdia o número do protocolo sempre que um documento já autorizado era reconsultado, falha causada pelo pacote de layout mais novo (2025), que não lia o protocolo devolvido pela SEFAZ. A correção passou a ler o protocolo corretamente e também impede que uma consulta sem retorno apague um protocolo já gravado.
TXPDE-7839Inclusão HOTFIX: 28/08/2026Correção
Correção do tipo do campo dhRecbto
ProblemaNo add-on MDF-e, quando a SEFAZ retornava um valor maior do que o suportado, era apresentada uma mensagem de erro interno, pois o campo dhRecbto estava definido como string, quando o tipo correto para armazenamento no banco de dados deveria ser NVARCHAR(30).
CorreçãoO tipo do campo dhRecbto foi corrigido para armazenar corretamente o retorno da SEFAZ. Ao iniciar o add-on, um migration é executado automaticamente aplicando o ajuste nas tabelas do banco de dados, sem necessidade de intervenção manual.
TXPDE-7811Inclusão HOTFIX: 12/08/2026Correção
Erro ao listar documentos na tela de Seleção de Documentos Fiscais NF-e / CT-e
ProblemaAo clicar em Listar na tela de Seleção de Documentos Fiscais NF-e / CT-e, o add-on MDFe apresentava um erro interno e impedia a consulta dos documentos disponíveis, pois a consulta ao banco pedia uma decisão que já era conhecida antes de ser montada, e o Hana não conseguia executá-la.
CorreçãoEssa decisão passou a ser resolvida no código, mantendo o resultado esperado. O mesmo problema no filtro de notas já vinculadas a manifesto também foi corrigido, pois quebraria nas mesmas condições.
NFe/NFCe
51 itens
TXPDE-8692Inclusão HOTFIX: 06/11/2026Correção
Erro ao visualizar XML de envio: caractere inválido 0x1F no documento XML
TXPDE-8620Inclusão HOTFIX: 04/11/2026Correção
Erro no envio de e-mail para a transportadora quando o PN não tem e-mail cadastrado
Problemacom o parâmetro "Enviar e-mail separado para transportadora" habilitado, o addon não enviava o e-mail para a transportadora quando o parceiro de negócio (PN) do documento não tinha e-mail cadastrado, mesmo que a transportadora tivesse. O processo era interrompido com exceção e nenhum e-mail era enviado.
Correçãoadicionada condição que verifica se há e-mail cadastrado no PN e se o parâmetro de e-mail separado para transportadora está habilitado, evitando a exceção e garantindo o envio normal do e-mail para a transportadora.
TXPDE-8661Inclusão HOTFIX: 03/11/2026Correção
DFe | NFSe | Ajuste no Preenchimento da Grid de Atualização
[Todas as prefeituras]
ProblemaNa tela de Atualização dos Add-Ons, a grid do histórico listava as versões de todos os Add-Ons aplicados, independentemente do produto selecionado.
CorreçãoAjustada a tela de atualização para exibir somente os dados do histórico pertencentes à versão que está em execução e ao produto selecionado.
TXPDE-8586Inclusão HOTFIX: 03/11/2026Correção
Monitor de Serviços altera sozinho o campo “Executa a cada ... segundos” de 5 para 15
ProblemaO Monitor de Serviços alterava sozinho o valor do campo "Executa a cada (segundos)" dos serviços durante a sincronização automática da lista: ao cadastrar um serviço sem tempo definido, o sistema forçava o valor padrão de 15 segundos; e para serviços já configurados, a rotina sobrescrevia periodicamente o valor definido pelo usuário, mesmo quando ele havia sido ajustado para outro número (ex.: 5 segundos).
CorreçãoA regra de sincronização foi ajustada para preservar a configuração do usuário: o tempo de execução de um serviço só é preenchido automaticamente quando ainda está vazio; se já existe um valor configurado, ele é mantido e não é mais sobrescrito pela rotina.
Implementar flag para desabilitar referência da tag NFref
Implementado(a) a possibilidade de marcar, na tela de Informação de referência das notas fiscais eletrônicas, documentos referenciados para que não sejam informados como referência da nota (tag NFref) no XML.
SINIEF nº 34/2026 | Implementar novo tipo "Retorno por recusa parcial na entrega (tpNFDebito = 09)" para Nota de débito (fiNFe = 6)
Implementado(a) o novo tipo 09 - Retorno por Recusa Parcial na Entrega para a Nota de Débito (finNFe = 6) do add-on NFe/NFCe, utilizando tpNFDebito = 09, conforme o Ajuste SINIEF nº 34/2026, que detalha os procedimentos de emissão nos cenários de recusa total, recusa parcial e não localização do destinatário na tentativa de entrega.
Observação: Para o tipo tpNFDebito = 09 (Retorno por Recusa Parcial na Entrega), a emissão ainda resulta em rejeição de schema, pois essa opção não foi incluída em Nota Técnica até o momento.
Implementado, para o estado de São Paulo, o mesmo tratamento de não destaque do ICMS-ST já existente para o Paraná: na nota de simples faturamento (entrega futura), o ICMS-ST deixa de ser destacado, passando a ser destacado apenas na nota de saída/entrega — corrigindo o comportamento anterior, que fazia o inverso (destacava o imposto na entrega futura e zerava na entrega). Para São Paulo, a regra também passou a considerar o CFOP da linha: o imposto só deixa de ser destacado quando o CFOP estiver entre os previstos (5922/6922 para a nota de entrega futura e 5116/6116 para a nota de entrega); nos demais CFOPs, o ICMS-ST continua sendo destacado normalmente.
NT 2025.002 v1.50 | Adequar schema do grupo gIBSCBSMono (tributação monofásica) – layout reformulado
Implementada a adequação do schema do grupo gIBSCBSMono (tributação monofásica de combustíveis) para o novo layout da NT 2025.002 v1.50 (pacote de schemas PL_010f v1.04), evitando a rejeição de schema (225) em notas com CST 620, que já ocorre em homologação e passa a ocorrer em produção a partir de 03/11/2026. O grupo passa a ser gerado na estrutura ad valorem para IBS e CBS (gIBSMonoAdValorem e gCBSMonoAdValorem).
⚙Configuração: É necessário habilitar o parâmetro "NT 2025.002 v1.50 – Atualização schema IBS/CBS monofásico" para que a adequação entre em vigor.
Observação: Em 2026 não há IBS/CBS monofásico devido sobre combustíveis (art. 348, III, "b", da LC 214/2025), por isso, nesta tarefa, apenas o schema foi atualizado e as alíquotas e valores continuam sendo gerados zerados.
Implementada a informação da Inscrição SUFRAMA do emitente na NFe/NFCe, conforme a NT 2025.002 v1.40. O dado é obtido a partir do campo SUFRAMA já existente no Cadastro de Entidade, sem criação de campo novo, e só é enviado na nota quando estiver preenchido no cadastro do emitente — entidades sem SUFRAMA não são afetadas. A validação do município (ZFM/ALC) e do dígito verificador fica a cargo da Sefaz, que rejeita a nota em caso de inconsistência.
Filtro no follow-up para consultar notas de débito e crédito
Implementada, no TaxPlus NFe/NFCe, a gravação na Process, no momento da autorização da NF-e, da classificação de nota de débito (tpNFDebito) ou de nota de crédito (tpNFCredito), por meio de dois novos campos mutuamente exclusivos — apenas um deles é preenchido, conforme a classificação da nota autorizada. Com base nessas informações, o FollowUp passou a oferecer um filtro para consultar notas de débito e de crédito por tipo; os demais tipos de operação (normal, ajuste, complemento, devolução etc.) não entram nesse filtro.
⚙️ Observação: o filtro e as informações só são válidos para notas emitidas após esta implementação; para notas emitidas anteriormente, não é possível realizar a consulta
Implementado(a) a atualização da tabela de Meios de Pagamento conforme o Informe Técnico 2024.002 v.1.11, com a inclusão dos novos códigos (20) Pagamento Instantâneo (PIX) – Estático, (21) Crédito em Loja, (22) Pagamento Eletrônico não Informado – falha de hardware do sistema emissor, (23) Pagamento Instantâneo (PIX) – Automático e (24) TEF – Book Transfer.
Implementado(a) o campo "Gerar Rastreabilidade?" no cadastro de Utilização do SAP Business One, permitindo suprimir a geração do grupo <rastro> (nLote, qLote, dFab, dVal, cAgreg) item a item, conforme a utilização informada na linha do documento. Quando o campo estiver como "Não definido" (padrão), o comportamento permanece inalterado; quando marcado como "Não", o grupo <rastro> não é gerado para o item, mesmo havendo lote vinculado e NCM habilitado. Essa nova regra tem prioridade sobre as já existentes (item gerenciado por série e NCM com "Gerar Rastreabilidade" = Não).
⚙Configuração: O campo "Gerar Rastreabilidade?" deve ser criado no cadastro de Utilização por meio da ação "Criar Campos".
Atualização legal | Criar parâmetro NT 2025.002 v1.52 - DFe Referenciado por item na devolução
Implementado(a) o parâmetro "NT 2025.002 v1.52 - DFe referenciado por item na devolução", disponível na nova sub-aba Notas Técnicas das configurações do NF-e. Quando marcado, as notas fiscais de devolução passam a referenciar o documento de origem exclusivamente no grupo DFeReferenciado, informado por item, conforme a regra de validação VC02-14 da NT 2025.002 v1.52. Quando desmarcado, mantém o processo padrão, com a referência no grupo NFref. O parâmetro pode ser copiado entre empresas pela tela de Replicar Configuração.
⚙Configuração: Marque este parâmetro a partir da data de obrigatoriedade em produção definida pela SEFAZ para a regra VC02-14.
Implementado(a) a sub-aba "Notas Técnicas" dentro da aba Reforma Tributária (Parâmetros Gerais > Dados Gerais > Reforma Tributária), reunindo os parâmetros "Considerar Nota Técnica XXXX" para ativação centralizada pelo cliente. Os parâmetros já existentes (Considerar Nota Técnica 2025.002 - RTC, Informações Complementares / Reforma Tributária, Validar existência cClassTrib e Habilitar Determinação de Classificação Tributária) permanecem na sub-aba Geral, e as próximas Notas Técnicas que exigirem ativação passam a ser adicionadas na nova sub-aba Notas Técnicas. A configuração vale por empresa e as opções também podem ser copiadas entre empresas pela tela de Replicar Configuração.
Implementado(a) a classificação automática de notas de débito e de crédito na NF-e (modelo 55) a partir da configuração de Utilização ("Utilização - Definição"), com os novos campos "Tipo de nota de crédito" e "Tipo de nota de débito". Ao selecionar uma utilização já configurada, o sistema assume automaticamente essa classificação na nota, respeitando a ordem de prioridade: primeiro os campos de usuário do documento de marketing, depois a utilização informada no rodapé do documento. Os dois campos são mutuamente exclusivos entre si e não exigem parâmetro de sistema para habilitação.
Implementado(a) um novo botão "Cancelar Evento" na tela de eventos da reforma, permitindo ao usuário selecionar um evento já autorizado e cancelá-lo, com envio imediato do cancelamento e barra de progresso. Quando a empresa utiliza transmissão pelo serviço, o cancelamento criado na tela é transmitido por ele, da mesma forma que os demais eventos da reforma. A decisão de cancelar é sempre manual, feita pelo usuário na tela — não há cancelamento automático nem via SAP.
Add-on altera o Enquadramento IPI para 999 quando utilizado CFOP de devolução
ProblemaAo emitir documentos com CFOP de devolução (ex.: 5201/6201) com o IPI destacado como despesa adicional, o Add-on alterava o Enquadramento do IPI na tag cEnq para 999, divergindo do valor parametrizado no cadastro fiscal (ex.: 326), o que ocasionava a rejeição 388 da SEFAZ.
CorreçãoAjustada a regra de preenchimento da tag cEnq, garantindo a manutenção do valor correspondente ao Enquadramento do IPI nos casos de emissão de documentos de marcação de devolução.
Implementado(a) a regra de prioridade de referenciamento de documentos na NF-e/NFC-e: quando o item possuir informação de referência na tag DFeReferenciado, o documento referenciado deixa de ser gerado também a nível de nota (tag NFref), conforme a Nota Técnica 2025.002 v.1.52, evitando a rejeição por referenciamento duplicado a nível de nota e de item.
Permitir informar outros tipos de embalagens no XML
Implementado(a) o parâmetro "Permitir informar outros tipos de embalagens no XML" para o add-on NF-e/NFC-e. Com o parâmetro ativo, o TaxPlus NFe passa a gerar um grupo <vol> para cada embalagem lançada na tela Lista de embalagem do documento, permitindo informar diferentes tipos e unidades de embalagem (caixa, pallet, saco, entre outros) na mesma nota; com o parâmetro desmarcado, o <vol> continua sendo gerado apenas a partir dos campos da aba Imposto. Os UDFs necessários (quantidade, espécie, marca, numeração e pesos dos volumes) são criados automaticamente pelo add-on na categoria "Documentos de marketing > Conteúdo da embalagem".
⚙Configuração: É necessário habilitar o parâmetro "Permitir informar outros tipos de embalagens no XML" para que o add-on passe a considerar as embalagens lançadas na tela Lista de embalagem.
Envio de E-mail altera o campo "StatusId" ao invés do campo "EmailStatusId"
ProblemaAo ocorrer um erro no envio do e-mail do documento (ex.: timeout), o sistema alterava o campo StatusId do documento perante a Sefaz, quando deveria alterar apenas o campo EmailStatusId, referente ao status do envio de e-mail.
CorreçãoO sistema foi corrigido para manter o StatusId do documento inalterado perante a Sefaz, registrando o erro do envio de e-mail apenas no EmailStatusId.
TXPDE-8353Inclusão HOTFIX: 07/10/2026Correção
Valores de estorno de crédito sendo levados para informações complementares na danfe quando o IBS/CBS estão com os valores zerados
Problemaquando a nota possuía itens com CST 410 (imunidade ou não incidência), o DANFE exibia valores de IBS/CBS nas informações complementares mesmo quando esses valores estavam zerados, o que causou reclamações de parceiros e clientes.
Correçãoos valores de IBS/CBS deixam de ser levados para as informações complementares da DANFE em itens com CST 410, abrangendo estorno de crédito (410026 e 410030), sem estorno (410001 e demais) e crédito presumido (410014 a 410017). O XML enviado à SEFAZ, incluindo o grupo de estorno de crédito, permanece inalterado.
TXPDE-8400Inclusão HOTFIX: 05/10/2026Correção
NFCom | Erro ao criar procedure com Hana 1.0
ProblemaNo ambiente de um cliente utilizando SAP HANA 1.0, a procedure transnotice do add-on não era compatível com essa versão do HANA, fazendo com que os documentos inseridos no SAP não fossem reconhecidos pelo add-on (mais de 25 mil documentos chegaram a ficar parados por conta do problema).
CorreçãoA procedure transnotice foi ajustada para ser compatível com o SAP HANA 1.0, resolvendo o problema de reconhecimento dos documentos.
Corrigir timer em produção de referência DFeReferenciado no copiar/para devolução
Corrigido(a) o timer de produção da referência DFeReferenciado no fluxo de copiar/para devolução, adequando a data de obrigatoriedade em produção para 03/11/2026, conforme a NT 2025.002 v1.52, que postergou o prazo anteriormente previsto (implementado originalmente na TXPDE-7819).
Implementada a inclusão da logomarca da empresa no layout da Carta de Correção (CCe), padronizando a apresentação visual do documento com a da Nota Fiscal Eletrônica.
ProblemaAo gerar o XML de envio de notas que fazem referência a outro documento, com a opção "Considerar chave de acesso do TripleOne" marcada, ocorria o erro "invalid column name: U_chaveacesso", pois o sistema passou a buscar a chave de acesso apenas no campo do TripleOne, que nem sempre existe nesse cenário.
Correçãoo sistema passou a buscar a chave de acesso em ambos os campos e utilizar o que existir, mantendo a opção "Considerar chave de acesso do TripleOne" marcada.
Tag competApur pode considerar período atual ou retroativo, atualmente é considerado a data do ambiente/servidor para gerar a informação de ano e mês no valor da tag
Implementado(a) campo de usuário TX_DtCompApur (Compet. Apuração Retroativa) para permitir informar a competência de apuração retroativa da tag competApur, conforme NT2025.002 v1.51. Quando não preenchido, mantém o comportamento atual de considerar o período vigente.
Ao gerar uma nota de devolução, a unidade tributável exterior não é levada para o XML
ProblemaAo gerar uma nota de devolução (documento de entrada) a partir de uma nota de saída com Unidade Tributável Exterior, o XML da devolução não levava a unidade tributável exterior (ex.: "KG"), pois o sistema só reconhecia a operação como "do exterior" quando era uma saída.
CorreçãoAjustamos o sistema para reconhecer a operação com o exterior tanto na saída quanto na entrada, corrigindo a geração do XML de devolução.
TXPDE-8041Inclusão HOTFIX: 11/09/2026Correção
O parâmetro “Definição <modBCST> automático conforme preço do produto (MVA ou Pauta)” está considerando o <modBCST> mesmo sem ICMS-ST configurado no código de imposto
ProblemaO parâmetro “Definição <modBCST> automático conforme preço do produto (MVA ou Pauta)” gerava as tags de ICMS-ST, incluindo a <modBCST>, mesmo em casos de CST 90 sem ICMS-ST configurado no código de imposto e sem percentual de MVA cadastrado, causando rejeição pela SEFAZ (código 932).
CorreçãoCorrigida a seleção automática da modalidade MVA, que passou a ser condicionada à existência do percentual de MVA cadastrado, sem alteração no restante do comportamento (valores, bases e alíquotas).
TXPDE-7957Inclusão HOTFIX: 09/09/2026Correção
Erro no formato de apresentação do valor do IBPT
ProblemaA mensagem de destaque do valor aproximado dos tributos (IBPT) estava sendo exibida em todas as notas, mesmo quando a operação não era para consumidor final, não respeitando o parâmetro do indicador do cliente.
CorreçãoFoi identificado que a checagem do indicador do cliente existia no cálculo, mas estava faltando na montagem da mensagem. Corrigido para que a mensagem de IBPT seja exibida apenas quando a operação for para consumidor final, ou quando o parâmetro de destacar para todos os clientes estiver habilitado.
Permitir exportar todo histórico do documento via follow-up
Implementada a opção de exportar o histórico do documento (NFe) selecionado no FollowUp, disponibilizando o arquivo em planilha Excel (.xls) com todos os processos realizados no documento.
"Não é possível visualizar o DANFE para documento com status estorno autorizado"
ProblemaNo Follow-up do TaxPlus NFe, após realizar o estorno de uma NF-e, o documento passava para o status “Estorno Autorizado”. Ao tentar visualizar/gerar o DANFE desse documento, o sistema informava que não era possível gerar o DANFE para documentos com esse status.
CorreçãoO status “Estorno Autorizado” foi incluído na lista de status habilitados para geração/visualização do DANFE.
TXPDE-7946Inclusão HOTFIX: 08/09/2026Correção
Inconsistências na emissão de Nota Fiscal de Crédito, finalidade 5 (Tipo 06 - Retorno por Recusa Parcial na Entrega)
ProblemaAo emitir Nota Fiscal de Crédito com finalidade 5, tipo 06 (Retorno por Recusa Parcial na Entrega), a transmissão retornava o erro "Cód. 225 - O elemento 'tpNFCredito' é inválido. O valor '06' é inválido para o tipo de dados 'TTpNFCredito'. Falha na restrição Enumeration.", embora a nota fosse autorizada normalmente ao retransmitir manualmente o mesmo XML pela tela de Follow-up.
CorreçãoA lista de tipos de nota de crédito utilizada na validação do schema do add-on foi atualizada para incluir o tipo 06 e os demais tipos que estavam faltando.
TXPDE-8186Inclusão HOTFIX: 04/09/2026Correção
Declaração de exportação buscando apenas pelo DocEntry e exibindo as declarações de outras entidades/bases
Problemaao abrir a declaração de exportação de uma Nota Fiscal de Saída, o add-on localizava o registro apenas pelo DocEntry, sem considerar a base/entidade. Com isso, em ambiente não CCC, a tela podia abrir já preenchida com os dados de uma declaração de exportação criada em outra base/entidade (nº da DE, data de registro, local de embarque etc. de outra empresa).
Correçãoa busca da declaração de exportação passou a considerar também a entidade/base do registro, na abertura da tela, na emissão individual e na emissão em lote. Quando não existe declaração daquela nota naquela empresa, a tela abre vazia para um novo cadastro, e os dados de exportação enviados para a nota são sempre os da própria empresa emissora.
Gerar grupo IBSCBS para cst 410 pelo campo de usuário do documento de marketing
Implementado(a) o suporte para geração do XML da NF-e quando o parâmetro Considerar CST/cClassTrib da linha do documento está marcado e a linha do item traz o CST 410 (Imunidade e não incidência), sem os dados da reforma tributária cadastrados no código de imposto. Nesse cenário, o grupo IBSCBS é gerado apenas com CST e cClassTrib, sem o grupo detalhado gIBSCBS, e o totalizador IBSCBSTot é gerado zerado. Os cClassTrib 410014, 410016, 410026 e 410030, que exigem crédito presumido ou estorno de crédito, continuam exigindo os dados no código de imposto, sem alteração.
Ajustar o parâmetro "Não gerar impostos (ICMS, PIS, COFINS) para nota de débito/crédito"
Corrigido(a) o comportamento do parâmetro "Não gerar impostos (ICMS, PIS, COFINS) para nota de débito/crédito", que passou a respeitar as exceções previstas na NT 2025.002 v1.51. Nos cenários de exceção (Crédito 03, 04 e 06, Débito 07, e tpNFDebito = "06-Pagamento Antecipado"), os impostos configurados no cadastro voltam a ser informados na nota; nos demais casos, continuam sendo removidos. As novas regras valem a partir de 01/09/2026 em homologação e 05/10/2026 em produção; clientes que não utilizam o parâmetro não têm alteração de comportamento.
Parâmetro "Remover os caracteres especiais nas informações adicionais da nota" causando divergências no processo
Problemao parâmetro "Remover os caracteres especiais nas informações adicionais da nota" também removia a quebra de linha das informações complementares da NFe/NFCe, mesmo quando o cliente precisava mantê-la com o parâmetro ativo.
Correçãocorrigido o método de formatação da tag infCpl para ignorar apenas os caracteres especiais que devem ser removidos, preservando a quebra de linha nas informações complementares.
Ao utilizar o parâmetro "Considerar a observação fiscal do código de imposto" e inserir observações de abertura e encerramento, os três devem constar no XML
Implementada a consideração simultânea das observações fiscais de abertura e de encerramento juntamente com a observação do código de imposto (quando o parâmetro "Considerar a observação fiscal do código de imposto" estiver habilitado), passando a incluir as três informações, quando preenchidas, no XML das notas fiscais de entrada e de saída.
Problema na criação das procedures ao iniciar os add-ons dos Docs Eletrônicos
ProblemaAo iniciar os add-ons dos Documentos Eletrônicos na versão 26.7.31.425, ocorriam erros de procedures invalidadas (ex.: sp_GetMovimento) devido à separação do módulo Fiscal no código-fonte do add-on, impactando a Análise de Movimento Fiscal em bancos SAP HANA.
CorreçãoCorrigidos os scripts de verificação/atualização de schema para garantir a criação e a persistência correta das procedures do TaxPlus Fiscal nesta hotfix.
TXPDE-7966Inclusão HOTFIX: 25/08/2026Correção
Erro no Retorno de Documentos Fiscais via API Postman
ProblemaAo obter o PDF de documentos fiscais (NF-e) em ambientes não CCC, o sistema retornava o erro "Invalid object name 'SBO_TaxOne..Process'", pois a consulta apontava para o banco SBO_TaxOne, que não possui a tabela Process — disponível apenas no banco DBInvOne.
CorreçãoCorrigido o apontamento da consulta para o banco correto (DBInvOne) em ambientes não CCC, restabelecendo a obtenção do PDF dos documentos fiscais.
Implementação do campo "indDoacao" Natureza da operação de doação
Implementado(a) o campo "Indicador de Doação" na linha do documento de marketing, com opções Sim/Não. Quando marcado como Sim, a informação é levada automaticamente ao XML na tag indDoacao, identificando o cenário da operação de doação para a tributação correspondente. Quando o campo estiver em branco ou marcado como Não, o comportamento das notas permanece inalterado.
Inconsistências no processo de Exportação Indireta.
ProblemaNo processo de Exportação Indireta de NF-e, a tela de Exportação podia ser aberta antes da respectiva Nota Fiscal de Saída ser adicionada no SAP, o que gerava erros e fazia com que fossem exibidos itens pertencentes a outra nota. Além disso, a listagem da Exportação Indireta continuava exibindo notas de entrada cujos itens já haviam sido consumidos em outras notas de saída, bem como notas com o campo Prazo para Exportação Indireta vencido ou com código de prazo zerado, e o botão "Inserir Chave" exibia mensagem de sucesso mesmo quando nenhum item era vinculado.
CorreçãoA tela de Exportação passou a abrir somente após a Nota Fiscal de Saída ser adicionada no SAP, eliminando os erros e a exibição de itens de outra nota. A listagem da Exportação Indireta agora mostra apenas as notas de entrada que servem aos itens da nota atual e que ainda possuem saldo, deixando de fora o que já foi consumido; notas com prazo vencido ou com código de prazo zerado deixaram de ser listadas e de ser usadas na geração das chaves, e alterações no código de prazo ou na quantidade de dias passam a valer imediatamente. Também foi corrigida uma falha na conferência dos prazos que lia a quantidade de dias de um cadastro errado. Por fim, o botão "Inserir Chave" deixou de exibir mensagem de sucesso quando nada foi vinculado, passando a avisar que não há nota de entrada válida disponível.
TXPDE-7536Inclusão HOTFIX: 18/08/2026Correção
Correção no funcionamento do campo de usuário "Destacar IPI na NF Futura?"
ProblemaAo emitir uma NF de Entrega Futura com o campo de usuário "Destacar IPI na NF Futura?" preenchido como "Não" e, em seguida, gerar uma Nota de Entrega a partir dela usando a função "Copiar para" do SAP Business One com o campo alterado para "Sim" no documento de destino, o add-on continuava considerando o valor original da NF Futura e enviava o IPI para a tag <outros>, ignorando o valor atualizado.
CorreçãoCorrigido para que o add-on sempre considere o valor atual do campo "Destacar IPI na NF Futura?" no documento que está sendo transmitido — quando "Sim", o IPI passa a ser destacado nas respectivas tags de IPI em vez de ir para <outros>. O comportamento para quem não altera o campo (vazio ou "Não") permanece o mesmo. O ajuste também passou a valer para o fluxo de Recebimento de mercadoria com o campo preenchido como "Sim".
NFe - Incluir coluna "Meio de Pagamento" no Follow-up.
Implementada a inclusão da coluna "Meio de Pagamento" na tela de Follow-up da NFe. O sistema exibirá a forma de pagamento definida na aba de contabilidade do documento de marketing (SAP); em casos de múltiplos pagamentos, será apresentada a primeira ocorrência preenchida na nota.
Tela de Follow-Up - Campo status de impressão e histórico, não apresenta informações sobre a impressão
ProblemaO campo de status de impressão e o histórico do follow-up não eram atualizados quando o DANFe era impresso manualmente pelo botão "Imprimir DANFe" — apenas a impressão automática pelo serviço gravava essas informações.
CorreçãoAgora toda impressão manual do DANFe grava o campo Status impressão como realizada e registra no histórico do follow-up a impressora utilizada e a quantidade de cópias. Em caso de falha na impressão ou de o arquivo do DANFe não ser encontrado, o status é registrado como erro, com o motivo no histórico. A coluna de status de impressão passou a aparecer no histórico do follow-up, com o registro vinculado à chave da nota. Vale tanto para o DANFe normal quanto para a DANFe simplificada, sem necessidade de configurar impressora por entidade.
TXPDE-7837Inclusão HOTFIX: 12/08/2026Correção
Layout da CCe cortando o nome da empresa
ProblemaO layout da Carta de Correção (CCe) cortava o nome da razão social da empresa quando o texto era longo.
CorreçãoO layout foi ajustado para exibir razões sociais de qualquer tamanho, inclusive os 60 caracteres previstos no MOC da NF-e, por completo, sem reduzir o tamanho da letra e sem deslocar as demais informações do documento.
TXPDE-7798Inclusão HOTFIX: 12/08/2026Correção
Consulta API no ReformaFast está apagando os registros de cClass
ProblemaA consulta via API no menu Reforma Fast apagava os demais registros de cClass da tabela ao trazer apenas alguns resultados, devido a um critério do BP-e aplicado indevidamente ao módulo de NF-e.
CorreçãoO critério de consulta do NF-e foi corrigido e centralizado em um único ponto do código, evitando divergências futuras. Também foi incluída uma classificação exclusiva de NFC-e que estava sendo ignorada, e a exclusão dos registros passou a ocorrer somente em conjunto com a regravação bem-sucedida — se a consulta falhar, nada é apagado.
TXPDE-7740Inclusão HOTFIX: 11/08/2026Correção
NFCe | Contingência EPEC de NFCe afetando modelo NFe
ProblemaAo alterar o modo de emissão da NFCe (modelo 65) para Contingência EPEC, o modo de emissão da NFe (modelo 55) também era alterado indevidamente.
CorreçãoFoi ajustada a verificação para considerar o modelo, corrigindo também duas trocas de configuração entre NF-e e NFC-e que gravavam o tipo de emissão de um modelo no outro.
TXPDE-7764Inclusão HOTFIX: 10/08/2026Correção
Erro de funcionalidade do parâmetro "Considerar CST/CClassTrib da linha do documento"
ProblemaIdentificado comportamento na geração do XML em cenários nos quais o cClassTrib é informado diretamente na linha do documento, fazendo com que o Add-on deixasse de buscar as informações de tributação regular (CSTReg e cClassTribReg) configuradas no código de imposto, gerando essas tags sem conteúdo no grupo gTribRegular.
CorreçãoCorrigido o comportamento do parâmetro "Considerar CST/cClassTrib da linha do documento". Agora, ao informar a classificação tributária na linha do documento, o sistema continua respeitando esse valor e, ao mesmo tempo, volta a buscar as informações de tributação regular configuradas no código de imposto quando elas não tiverem sido preenchidas na linha. A busca segue a ordem: primeiro a linha do documento, depois o código de imposto e, por último, o item. Para quem usa apenas o código de imposto, não há mudança de comportamento.
TXPDE-7819Inclusão HOTFIX: 07/08/2026Correção
Correção no processo de referência DFeReferenciado.
ProblemaA referência ao documento de marketing de devolução estava sendo feita sempre por meio da tag <DFeReferenciado>, mesmo quando a nota fiscal tinha finalidade de nota de crédito (finNFe = 4), caso em que a referência correta deveria ser feita pela tag <refNFe>.
CorreçãoAjustado o processo para que, quando a finalidade da NF-e for nota de crédito (finNFe = 4), a referência ao documento de marketing de devolução seja feita pela tag <refNFe>, mantendo-se <DFeReferenciado> para os demais casos. Por ora, essa regra vale apenas para notas emitidas em ambiente de homologação; a previsão de disponibilização em produção é 05/10/2026.
Erro ao editar um Código do Beneficio Fiscal por UF que já havia sido previamente cadastrado
ProblemaAo editar um Código de Benefício Fiscal por UF já cadastrado, o sistema exibia indevidamente uma mensagem de erro de duplicidade — mesmo assim, a edição era aplicada normalmente pouco tempo depois.
em InvoiceOne.DI.Settings.BeneficioFiscalGrupo.ValidarDuplicidade()
CorreçãoA validação de duplicidade estava comparando o registro com ele mesmo, causando o erro indevido ao editar. Agora a edição salva normalmente na primeira tentativa, sem mensagem de erro, e a validação ficou mais rápida (antes verificava a tabela inteira a cada gravação). Na importação por Excel, linhas repetidas dentro do próprio arquivo passam a ser ignoradas em vez de interromper a importação. A verificação de duplicidade continua ativa, bloqueando o cadastro de dois registros com a mesma combinação de Grupo de Itens + CST + UF + Vigência.
Implementada a DANFE Simplificada do Tipo 2, conforme a Nota Técnica 2026.003 v1.00. O novo modelo padroniza a emissão simplificada para operações destinadas à NFC-e, incluindo suporte aos novos impostos IBS/CBS. O fluxo de contingência foi equalizado ao padrão offline da NFC-e para garantir consistência no comportamento e na emissão do documento.
Ambiente Nacional | Considerar o campo de usuário: U_TX_Just - Justificativa NF-e/NFC-e
[Ambiente Nacional]
ProblemaNo cancelamento via serviço, ao preencher o campo de usuário U_TX_Just - Justificativa NF-e/NFC-e, o status da NFSe mudava para “Pedido de Cancelamento”, mas o conteúdo do campo não era considerado na geração do XML, enviando a tag xMotivo vazia e retornando o erro “E1235 - Falha no esquema XML do DF-e.. The 'http://www.sped.fazenda.gov.br/nfse:xMotivo' element is invalid - The value '' is invalid according to its datatype 'http://www.sped.fazenda.gov.br/nfse:TSMotivo' - The Pattern constraint failed.”
CorreçãoO processo de cancelamento (manual e via serviço) passou a obter a justificativa a partir do campo de usuário U_TX_Just, com validação do tamanho mínimo exigido — quando insuficiente, o cancelamento manual orienta o usuário, e o cancelamento via serviço marca a nota como Erro Interno antes de comunicar com o Emissor Nacional.
[NFS-e][Prefeitura de Belém - PA] Retornar PDF para padrão municipal
[Prefeitura de Belém – PA]
Corrigido o PDF da NFS-e e do RPS da Prefeitura de Belém – PA, que estava sendo gerado no leiaute Nacional em vez do padrão municipal, devido a uma alteração que afetou todos os municípios do provedor IMA. Belém voltou a emitir no modelo municipal, tanto na emissão pelo leiaute atual quanto na emissão pela reforma tributária, e passou a incluir o QR Code de autenticação da nota, que antes saía vazio.
[NFS-e] [Prefeitura de Araraquara - SP] Alteração no link do WS
[Prefeitura de Araraquara – SP]
Implementada a atualização da URL do webservice de emissão de NFS-e da Prefeitura de Araraquara – SP, que passou a ser https://araraquara.sisvetor.com.br/ords/pma/ws/nfe/emitir_nfe.
TXPDE-8635Inclusão HOTFIX: 29/10/2026Correção
[NFS-e][Prefeitura de Santo André - SP][2.0] Envio da tag evento vazia.
[Prefeitura de Santo André – SP]
Problemana emissão de NFS-e da Prefeitura de Santo André – SP, a nota era enviada com a tag de evento vazia, mesmo sem nenhuma informação de evento preenchida.
Correçãoa tag de evento agora só é enviada quando há identificação ou descrição do evento preenchida. Se as duas estiverem em branco, a tag é omitida.
TXPDE-8631Inclusão HOTFIX: 29/10/2026Correção
[NFS-e][Prefeitura de Campinas - SP] Ajuste no local de incidência do PDF.
[Prefeitura de Campinas – SP]
ProblemaO PDF gerado pelo add-on apresentava divergência no local de incidência, pois o campo era obtido de forma incorreta, sem considerar que essa informação não é enviada no XML de envio.
CorreçãoAjustada a geração do PDF para que o campo de incidência seja obtido corretamente a partir do XML autorizado.
TXPDE-8632Inclusão HOTFIX: 28/10/2026Correção
[NFS-e][Prefeitura de Franca - SP] Ajuste no valor liquido quando tem ISS retido.
[Prefeitura de Franca – SP]
ProblemaO valor líquido da NFS-e não considerava o abatimento do ISS retido, gerando a rejeição "Rejeitado pela regras municipais: O Valor Líquido da Nota Fiscal não confere com o calculado. Valor incorreto: 276.08. Valor esperado: 267.38".
CorreçãoO cálculo do valor líquido da NFS-e foi ajustado para abater corretamente o valor do ISS retido.
TXPDE-8624Inclusão HOTFIX: 28/10/2026Correção
[NFS-e] [Prefeitura de São Bernardo do Campo - SP] Pedido de Cancelamento Correção URL GissOnline
[Prefeitura de São Bernardo do Campo – SP]
ProblemaA URL do município de São Bernardo do Campo estava incorreta na versão GissOnline 2.0.
CorreçãoCorrigimos a URL e testamos a comunicação com o provedor. A autorização da nota de teste não ocorreu porque a senha do certificado digital informado estava incorreta, o que é um problema do lado do cliente e não do add-on.
TXPDE-8619Inclusão HOTFIX: 28/10/2026Correção
[NFS-e] [Prefeitura de Itaúna - MG] Pedido de Cancelamento com Erro de Estrutura
[Prefeitura de Itaúna – MG]
ProblemaNa NFS-e de Itaúna-MG (provedor Nota Control Nacional), o pedido de cancelamento era rejeitado por erro de estrutura do XML (código E160), e a nota não era cancelada. Depois do cancelamento, a consulta da nota também passava a falhar com erro, em vez de mostrá-la como cancelada.
CorreçãoO cancelamento passou a ser enviado no layout de evento do padrão nacional, e a resposta da prefeitura com o evento de cancelamento passou a ser reconhecida como sucesso. As consultas passaram a retornar a nota como "Cancelada", sem erro.
Ambiente Nacional | Implementar NT 009 Release 1 (produção em 01/12/2026) - Fase 01 (adequação schema/XSD)
[Ambiente Nacional]
Implementado(a) o ajuste do XML da NFSe para o novo leiaute do Ambiente Nacional definido pela NT 009 Release 1 (Fase 01 – adequação de schema/XSD), que entra em produção em 01/12/2026 e já é exigido no ambiente de produção restrita. O campo finNFSe foi reposicionado para a raiz do infDPS (antes ficava dentro de IBSCBS); os campos CST e cClassTrib deixaram de ficar dentro de gIBSCBS e passaram a ficar diretamente em IBSCBS/valores/trib; e xDescServ passou a ser o último elemento de cServ, após cNBS. Não foram criados campos, tabelas ou telas novas, e as alterações são aplicadas automaticamente, sem necessidade de marcar nenhum parâmetro.
[NFS-e] [Provedor Megasoft] Novos campos da Reforma
[Provedor Megasoft]
Corrigido(a) rejeição de NFS-e referente aos novos campos da Reforma Tributária para o provedor Megasoft. Os campos foram implementados seguindo as mesmas regras e preenchimentos dos campos de mesmo nome ou similares da NFS-e Nacional, como os dados de Evento, Imóvel e Comércio Exterior.
TXPDE-8607Inclusão HOTFIX: 23/10/2026Correção
[NFS-e] [Prefeitura de Divinópolis - MG] Ajuste na regra de envio de alíquota quando configurado o envio da NFS-e nacional.
[Prefeitura de Divinópolis – MG]
ProblemaQuando configurado o envio da NFS-e nacional, o complemento continuava aplicando a regra do provedor Betha para obtenção da alíquota quando o regime especial não estava preenchido, regra que deveria valer apenas no ambiente municipal. Isso causava o envio indevido da alíquota e, consequentemente, a rejeição do documento.
CorreçãoFoi adicionada uma exceção para que a regra do provedor Betha de obtenção da alíquota só seja aplicada quando o parâmetro Usar emissor nacional não estiver ativo nos municípios que utilizam esse provedor.
[NFS-e] [Prefeitura de Pirapora do Bom Jesus - SP] Atualização link WS + Novo Layout Nacional
[Prefeitura de Pirapora do Bom Jesus – SP]
Corrigido(a) o atendimento ao webservice da prefeitura no layout nacional: as notas emitidas por esse município não eram comunicadas corretamente e a consulta da NFS-e já emitida também não retornava o resultado esperado, pois o município não estava configurado com o novo endereço do provedor e a consulta usava um formato de chamada incompatível com o serviço, reconhecendo como sucesso apenas uma das respostas possíveis. Foi cadastrado o novo endereço do webservice, a consulta passou a ser feita pela chave da nota e a resposta de sucesso do serviço passou a ser reconhecida corretamente, com o município marcado como sem consulta por RPS e com consulta por número e chave.
[NFS-e][Ambiente nacional] Ajuste no envio da tag cPaisResult.
[Ambiente Nacional]
Corrigido(a) o envio da tag cPaisResult no XML da NFS-e do Ambiente Nacional para tomador estrangeiro tributado fora do município: quando não há local de prestação informado no add-on, a tag deixa de ser enviada dentro de tribMun; quando o local de prestação é informado, a tag passa a ser enviada corretamente. Essa inconsistência causava a rejeição E0591 nesses cenários. Não há mudança no cenário de tomador estrangeiro tributado dentro do município.
TXPDE-8597Inclusão HOTFIX: 22/10/2026Correção
[NFS-e][Prefeitura de Paulínia - SP] Ajuste no valor do PIS do XML de envio quando habilitado o parâmetro “considerar ABNT NBR 5891 para cálculo dos valores no XML”
[Prefeitura de Paulínia – SP]
ProblemaNo add-on, quando o parâmetro "Considerar ABNT NBR 5891 para cálculo dos valores no XML" estava habilitado, o PIS e o COFINS eram levados com alíquota retida e valor não retido, causando a rejeição "Valor de PIS inconsistente com Alíquota".
CorreçãoAjustado para que o add-on atribua o valor e a alíquota de PIS e COFINS de acordo com o tipo de imposto retido (tpRetPisCofins): havendo valores retidos, são considerados os retidos; não havendo, são considerados os não retidos (apuração própria). A regra vale independentemente do parâmetro estar habilitado. Correção aplicada para os provedores Ginfes e GissOnline.
[NFS-e][Prefeitura de Jundiaí - SP] Geração do DANFS-e no layout nacional 2.0
[Prefeitura de Jundiaí – SP]
Corrigido(a) a geração do DANFS-e para a Prefeitura de Jundiaí – SP, que estava sendo emitido no layout municipal antigo; a geração passa a seguir o layout nacional 2.0, igual ao documento emitido pela prefeitura.
[NFS-e] [João Pessoa - PB] Incluir URL de produção do WebService que atende a reforma tributária
[Prefeitura de João Pessoa – PB]
Implementada a URL de produção do provedor IMA para o município de João Pessoa – PB, referente à emissão de notas fiscais da reforma tributária: https://nfseapi.joaopessoa.pb.gov.br/notafiscal-ws
[NFS-e][Prefeitura de Guarulhos - SP] Geração do DANFS-e no layout nacional 2.0
[Prefeitura de Guarulhos – SP]
Corrigido(a) a geração do DANFS-e para a Prefeitura de Guarulhos – SP, que estava sendo emitido no layout municipal (modelo antigo) da prefeitura. Agora a geração passa a utilizar o layout nacional 2.0, conforme padrão vigente para o município.
[NFS-e] [Prefeitura de São Paulo - SP] Situação tributaria "R" e "S"
[Prefeitura de São Paulo – SP]
Implementado(a) o campo de usuário TX_TpTribSaoPauloSp, utilizado exclusivamente para documentos emitidos para o município de São Paulo – SP, permitindo informar manualmente a situação tributária (ex.: tributado, isento, imune, exigibilidade suspensa, exportação de serviços) a ser considerada na geração do XML. Quando preenchido, o valor do campo tem prioridade sobre a regra padrão baseada na natureza da operação; quando vazio, a regra padrão é mantida.
TXPDE-8550Inclusão HOTFIX: 16/10/2026Correção
Provedor Centi| Rejeição valor do CSLL apenas no campo legado ValorCSll ou no novo campo VretCSLL
[Provedor Centi]
ProblemaAo gerar NFSe com CSLL retida para o provedor Centi, o sistema retornava a rejeição "Erro informação ambígua: informe o valor do CSLL apenas no campo legado ValorCSll ou no novo campo VretCSLL", impedindo a emissão do documento com retenção.
CorreçãoA geração das notas com retenção foi atualizada para o provedor Centi, que agora utiliza exclusivamente o campo VlRetCSLL para o somatório das retenções de PIS, COFINS e CSLL.
[NFS-e] [Prefeitura de São Paulo - SP] PDF do SAP divergente do PDF da Prefeitura
[Prefeitura de São Paulo – SP]
Corrigido(a) o PDF da NFS-e/RPS de São Paulo – SP com reforma tributária (IBS/CBS), que estava divergente do PDF da Prefeitura: não exibia a "Localidade de Prestação" e a "Localidade de Incidência" aparecia sem a UF. O layout foi ajustado e o PDF passou a exibir a "Localidade de Prestação" (código IBGE, cidade e UF), com a "Localidade de Incidência" agora incluindo a UF.
[NFS-e] [Prefeitura de Jequié - BA] Novo link para envio da reforma tributaria.
[Prefeitura de Jequié – BA]
Corrigido(a) o link de comunicação utilizado no envio de NFS-e emitidas com a reforma tributária para o município de Jequié – BA, que estava causando erro interno de comunicação no momento do envio. Foi identificado e implementado o novo link de envio disponibilizado pelo portal da prefeitura, e os testes em produção restrita confirmaram a autorização e o cancelamento de notas fiscais.
⚙Configuração: É necessário preencher o token de emissão fornecido pelo provedor no campo Senha, em Parâmetros Gerais, para a emissão de NFS-e deste município.
TXPDE-8528Inclusão HOTFIX: 15/10/2026Correção
[NFS-e] [Prefeitura de Sorocaba - SP] Ao tentar gerar PDF autorizado vai para link com erro e arquivo PDF não é gerado
[Prefeitura de Sorocaba – SP]
ProblemaNa NFS-e da Prefeitura de Sorocaba/SP, ao tentar obter o PDF de um documento autorizado, o AddOn direcionava o usuário para um link da prefeitura que retornava erro, e o arquivo PDF não era gerado.
CorreçãoSorocaba deixou de usar o link externo do provedor e passou a gerar o PDF diretamente no AddOn, no layout nacional, com a exportação de PDF e a visualização de RPS habilitadas para o município.
[NFS-e] [Prefeitura de Rio Grande - RS] Mudança de link do WS.
[Prefeitura de Rio Grande – RS]
Implementado(a) a atualização do link do webservice da Prefeitura de Rio Grande – RS, que passou a adotar o padrão nacional de envio (SIGISS Nacional) e agora exige o envio das tags ibs/cbs referentes à reforma tributária.
[NFS-e] [Prefeitura de Santana de Parnaíba - SP] Atualização Link WS e Layout
[Prefeitura de Santana de Parnaíba – SP]
Implementada a atualização do link do webservice de produção do provedor Simplissweb para o município de Santana de Parnaíba – SP, que passou a adotar o layout nacional. Foram realizados testes em homologação com notas autorizadas, com e sem reforma; os testes em produção serão feitos junto ao cliente.
TXPDE-8523Inclusão HOTFIX: 14/10/2026Correção
[NFS-e] [Prefeitura de Palhoça - SC] Gerando as tags "aliquota_cofins" e "aliquota_pis" com ponto no lugar da virgula
[Prefeitura de Palhoça – SC]
Problemaao enviar a NFS-e pelo monitor de serviço, as tags aliquota_cofins e aliquota_pis eram geradas com ponto no lugar de vírgula, fazendo com que o documento fosse rejeitado pelo município com o erro "Error 1839: Element 'aliquota_pis': [facet 'pattern'] The value '1.65' is not accepted by the pattern...".
Correçãoos campos de valores de PIS e COFINS passaram a ser informados com formatação fixa no padrão brasileiro, sem ponto como separador decimal (exemplo: 1000,00).
[NFS-e] [Prefeitura de Itaguaí - RJ] Adequação a reforma
[Prefeitura de Itaguaí – RJ]
Corrigido(a) problema na comunicação de NFS-e da Prefeitura de Itaguaí/RJ, que utilizava uma integração antiga, desatualizada e não aderente ao novo padrão nacional exigido pela Reforma Tributária. No fluxo de cancelamento, a identificação da nota era enviada em formato incorreto e o sistema não reconhecia corretamente os erros retornados pela prefeitura, fazendo com que cancelamentos rejeitados fossem registrados como concluídos. O município passou a utilizar a mesma comunicação nacional já adotada por outros municípios atendidos pelo mesmo provedor, com a correção do formato de identificação enviado no cancelamento e do reconhecimento de erros retornados.
TXPDE-8510Inclusão HOTFIX: 13/10/2026Correção
[NFS-e] [Provedor Tiplan] Campo de usuário "Informar Alíquota ISS Nacional" não está gerando a TAG pAliq quando informado "Sim"
[Provedor Tiplan]
ProblemaNa emissão de NFS-e para clientes dos municípios atendidos pelo provedor Tiplan (Americana/SP, Macaé/RJ, Rio das Ostras/RJ e Mangaratiba/RJ), com a Reforma Tributária habilitada, o campo de usuário "Informar Alíquota ISS Nacional" marcado como "Sim" não tinha efeito algum, fazendo o documento fiscal ficar com a alíquota do ISS incorreta.
CorreçãoO provedor Tiplan foi incluído na lista de provedores que seguem o layout nacional de NFS-e, passando a respeitar corretamente a configuração do campo de usuário e a enviar a alíquota do ISS na nota sempre que "Sim" estiver selecionado.
[NFS-e] [Nacional] PDF em desacordo com extraído do portal nacional
[Ambiente Nacional]
Corrigido(a) a geração do PDF da NFS-e Nacional, que agora exibe o trecho de informações do Simples Nacional independentemente da existência ou do valor no XML, eliminando a divergência em relação ao PDF extraído diretamente do Portal Nacional.
TXPDE-8502Inclusão HOTFIX: 13/10/2026Correção
[NFS-e] [Prefeitura de Santa Barbara D' Oeste - SP] Formato da data no XML de envio
[Prefeitura de Santa Bárbara d'Oeste – SP]
ProblemaNa emissão de NFS-e para a prefeitura de Santa Bárbara d'Oeste (SP) e demais municípios atendidos pelo mesmo provedor (Valinhos, Araras, Leme, Sumaré e Santa Gertrudes), a data de emissão podia ser enviada à prefeitura em um formato incorreto, divergente do esperado pelo webservice municipal.
CorreçãoA formatação da data de emissão foi fixada para sempre seguir o padrão brasileiro (dia/mês/ano), independentemente da configuração regional do servidor, eliminando a variação que causava o problema.
TXPDE-8483Inclusão HOTFIX: 09/10/2026Correção
[NFS-e] [Prefeitura de Campinas - SP] Ajuste no envio de cancelamento via WS.
[Prefeitura de Campinas – SP]
ProblemaO cancelamento de NFS-e de Campinas/SP estava sempre falhando, mesmo quando os dados da nota estavam corretos.
CorreçãoCorrigido o endereço de comunicação com a prefeitura e ajustada a forma como o sistema interpreta a resposta recebida, passando a reconhecer corretamente as mensagens de erro e evitando que uma nota seja marcada como cancelada quando o cancelamento não foi realmente aceito.
[NFS-e] [Provedor E&L] Ajuste na consulta por RPS // Ajustar consulta quando houve a retorno "em processamento adn nacional".
[Provedor E&L]
Corrigido(a) o tratamento do retorno "em processamento adn nacional" no provedor E&L: ao receber esse retorno no envio assíncrono, a nota passa a ficar em Aguardando Retorno e é consultada automaticamente até um limite configurado, sendo autorizada assim que a prefeitura confirmar o processamento ou podendo ser recuperada pela Consulta por RPS caso o limite seja atingido. Também foram corrigidos os erros ocorridos na Consulta por RPS, na consulta por número da NFS-e e no cancelamento.
⚙Configuração: disponibilizado parâmetro de Método de Envio (Síncrono/Assíncrono) e limite de consultas de lote para o provedor.
[NFS-e] [Prefeitura de Santa Bárbara d'Oeste - SP] Ausência das tags destinatario IBS/CBS
[Prefeitura de Santa Bárbara d'Oeste – SP]
Corrigido(a) a geração das tags de destinatário do IBS/CBS na NFSe, que deixavam de ser enviadas quando INDICADOR_OPERACAO era diferente de 100301, causando rejeição no retorno da prefeitura nos casos em que o próprio tomador do serviço era o destinatário do IBS/CBS.
[NFS-e] [Prefeitura de Jataí - GO] Novo WS da prefeitura.
[Prefeitura de Jataí – GO]
Implementado(a) a integração com o novo webservice (Centi) da prefeitura de Jataí – GO para emissão e impressão de NFS-e, substituindo a integração anterior (Sigep), que havia se tornado inoperante. Também foi corrigido o cancelamento de notas emitidas pela nova integração, que passou a utilizar o código de verificação correto retornado pela prefeitura, evitando o erro de "nota não encontrada".
TXPDE-8472Inclusão HOTFIX: 08/10/2026Correção
[NFS-e] Tela FollowUp - Mostrar Linha Auto Filtro - Erro no uso
[Todas as prefeituras]
ProblemaNa tela de Follow Up de NFS-e, ao clicar com o botão direito no cabeçalho das colunas e ativar a opção "Mostrar Linha Auto Filtro", o sistema apresentava um erro inesperado e travava a tela, mesmo sem nenhuma linha de nota selecionada.
CorreçãoO sistema agora reconhece quando o foco está sobre essa linha especial de filtro, sem dados de nota associados, e simplesmente limpa o histórico exibido, sem tentar processar dados inexistentes, evitando o erro.
[NFS-e] [Prefeitura de São José - SC] Divergência PDF chave do nacional
[Provedor IPM / IPM 2.0]
Implementado(a) o envio assíncrono para os provedores IPM e IPM 2.0, com um novo parâmetro de configuração para definir o modo de emissão (síncrono ou assíncrono). No fluxo assíncrono, a nota fica com status "Aguardando Retorno" e o add-on enfileira a consulta de lote pela chave; somente após o retorno dessa consulta a nota é definida como autorizada, absorvendo a chave de acesso retornada pelo campo chave_acesso_nfse_nacional do Ambiente Nacional. Isso elimina a divergência entre a chave exibida no PDF do add-on e a chave constante no portal nacional.
⚙Configuração: para evitar a divergência de chave no PDF, habilite o parâmetro de modo de emissão (síncrono/assíncrono) do provedor IPM/IPM 2.0 e configure-o como assíncrono.
TXPDE-8379Inclusão HOTFIX: 08/10/2026Correção
[NFS-e][Ambiente Nacional] Envio da tag <cpaisresult> para ISS de exportação.
[Ambiente Nacional]
ProblemaAo emitir uma NFS-e no Ambiente Nacional com a tributação de ISS marcada como "Exportação de serviço", o sistema era rejeitado pela prefeitura/Receita com o erro E0590 por falta da informação do código do país onde ocorreu o resultado do serviço prestado.
CorreçãoAjustado o cálculo do local de prestação do serviço e a identificação de notas de exportação, passando a considerar corretamente tanto os casos em que o imposto é cobrado no local do cliente quanto os casos em que é cobrado pela regra padrão, garantindo o envio da tag <cpaisresult> quando exigida.
[NFS-e] [Provedor GissOnline] Atualização link WS HOMOLOGAÇÃO
[Provedor GissOnline]
Implementada atualização do link do Web Service (WS) de homologação do provedor GissOnline.
TXPDE-8449Inclusão HOTFIX: 07/10/2026Correção
[NFS-e][Prefeitura de Ponta Grossa - PR] Ajuste no envio da NFS-e.
[Prefeitura de Ponta Grossa – PR]
Problemaao realizar o envio da NFS-e ocorria erro interno por URL inválida, embora o link do WS da prefeitura estivesse ativo, impedindo a autorização do documento.
Correçãoajustado o link de envio do Web Service (WS) para a Prefeitura de Ponta Grossa – PR.
[NFS-e][Prefeitura de Santos - SP] Ajuste no PDF gerado pelo add-on
[Provedor Ginfes e GissOnline]
Corrigido(a) a divergência entre o PDF gerado pelo add-on e o PDF gerado pela prefeitura para os provedores Ginfes e GissOnline: o add-on utilizava o modelo nacional para a geração do PDF da NFS-e, o que causava diferenças em relação ao padrão municipal adotado pelas prefeituras. O modelo de geração do PDF do add-on foi ajustado para corresponder ao utilizado por cada prefeitura atendida pelos provedores Ginfes e GissOnline.
TXPDE-8446Inclusão HOTFIX: 06/10/2026Correção
[NFS-e][Prefeitura de Maragogi - AL] Ajuste no envio do país para tomador estrangeiro tributado no municipio.
[Prefeitura de Maragogi – AL]
ProblemaNa emissão de NFS-e para prestadores atendidos pelo padrão Tributus (ex.: Maragogi/AL), quando a nota era para um tomador estrangeiro classificado como tributação no município, o sistema enviava à prefeitura o código do país do tomador, informação que, nesse cenário específico, não deveria ser enviada.
CorreçãoPassou a ser verificado também se a operação é tributada no município antes de enviar o código do país: nesse caso, o campo deixa de ser enviado; nos demais casos de exportação, o envio continua normalmente como antes.
[Prefeitura de Paranaguá – PR]
Implementada a adequação ao novo sistema do município de Paranaguá – PR (provedor Elotech), em substituição ao WebService anterior, incluindo atualização do layout do PDF da NFS-e para o modelo DANFSe 2.0 da NFSe Nacional. Os testes de comunicação com o novo provedor foram realizados com sucesso; a emissão de nota autorizada em ambiente de produção ainda depende do fornecimento de usuário e senha do portal pela prefeitura.
[NFS-e] [Rio Branco - AC] Alteração do WS do município
[Prefeitura de Rio Branco – AC]
Atualizado o suporte à emissão de NFS-e do município de Rio Branco - AC, que passou a utilizar o provedor E&L 2.04. A emissão é feita pelo add-on, com PDFs gerados pelo próprio add-on, exigindo frase secreta/senha e certificado digital. Não há ambiente de homologação disponível para esse município. O município suporta consulta de NFS-e por RPS e aceita cancelamento. Os campos Item da LC 116 e Código de Tributação devem ser informados no formato XX.XX (ex.: 17.05).
📖 Documentação: Como configurar o município Rio Branco - AC para emitir NFS-e
[NFS-e] [Prefeitura de Eusébio - CE] Criar PDF Invent
[Provedor E&L]
Corrigido(a) a geração do PDF da NFS-e para o provedor E&L, que antes abria uma tela de autenticação ao invés de exibir o PDF do documento. Agora o add-on gera um PDF próprio (PDF Invent): para notas que não são da reforma tributária, o PDF Municipal é composto a partir do XML autorizado quando NFS-e, ou dos dados da nota do SAP, parâmetros e entidade quando RPS; para notas da reforma tributária, é gerado o DANFSe 2.0 da NFS-e Nacional a partir dos dados da nota do SAP, parâmetros e entidade. Também foi adicionada parametrização para manter a visualização do PDF via link, para clientes que ainda queiram utilizá-la.
[NFS-e] [Rio Grande - RS] [Provedor SigIss] Atualização do WebService para atender a Reforma Tributária / NFS-e Nacional
[Prefeitura de Rio Grande – RS]
Implementada adequação do WebService de integração com a Prefeitura de Rio Grande – RS (Provedor SigIss) para atender à Reforma Tributária, com envio das notas no layout da NFS-e Nacional e emissão da DANFSe 2.0 para representação visual do documento (PDF).
[NFS-e] [Prefeitura de Campinas - SP] Atualização Link WS
[Prefeitura de Campinas – SP]
Implementada atualização do link do Web Service (WS) de produção da Prefeitura de Campinas – SP, em atendimento à reforma tributária.
TXPDE-8414Inclusão HOTFIX: 01/10/2026Correção
[NFS-e][Provedor Giss Online 2.0] Não enviar tag de outras retenções quando o valor for 0.00
[Provedor Giss Online 2.0]
ProblemaNa emissão de NFS-e por clientes atendidos pelo provedor GISS Online, o sistema enviava à prefeitura a tag OutrasRetencoes mesmo quando não havia nenhum valor retido (R$ 0,00), causando rejeição do documento na maioria dos municípios desse provedor.
CorreçãoA regra de envio da tag OutrasRetencoes passou a verificar se há de fato um valor de retenção diferente de zero antes de enviá-la à prefeitura, mantendo sem alteração o tratamento específico já existente para o município de Maceió/AL.
TXPDE-8408Inclusão HOTFIX: 30/09/2026Correção
[NFS-e][Prefeitura de São Paulo - SP] Ajustar PDF//RPS no documento de entrega.
[Prefeitura de São Paulo – SP]
ProblemaO PDF da NFS-e gerado pela tela de entrega ficava divergente do PDF gerado pela tela de saída, sem a segunda página referente à reforma tributária e sem destacar os impostos de PIS/COFINS.
CorreçãoA obtenção dos dados foi ajustada para que o add-on passe a considerar qualquer documento vinculado à Doc na composição dos dados da NFS-e autorizada nas prefeituras, provedores e no Emissor Nacional, permitindo usar a Entrega de Mercadoria como documento base e obtendo os dados de IBS/CBS necessários para gerar a segunda página e destacar corretamente os impostos.
TXPDE-8362Inclusão HOTFIX: 29/09/2026Correção
[NFS-e] [Prefeitura de Mogi das Cruzes - SP] Erro de assinatura ao enviar XML editado
[Prefeitura de Mogi das Cruzes – SP, Arujá – SP, Bauru – SP, Franca – SP, Jandira – SP, Itapevi – SP, Cubatão – SP, Cariacica – ES e Vila Velha – ES]
ProblemaAo editar manualmente o XML de uma NFS-e e reenviá-lo pela funcionalidade de "enviar XML editado" para a prefeitura de Mogi das Cruzes/SP e demais municípios atendidos pelo mesmo provedor, o sistema retornava erro de assinatura e a nota não era processada.
CorreçãoO reenvio de XML editado passou a assinar digitalmente o documento (quando há certificado configurado) antes de enviá-lo, alinhando esse fluxo ao comportamento já usado na emissão normal.
TXPDE-8348Inclusão HOTFIX: 28/09/2026Correção
[NFS-e][Prefeitura de Ferraz de Vasconcelos - SP] Ajuste no PDF do add-on quando emitido com a reforma tributaria.
[Prefeitura de Ferraz de Vasconcelos – SP, Bebedouro – SP, Bragança Paulista – SP, Mococa – SP e Taboão da Serra – SP]
ProblemaAo emitir uma NFS-e com a Reforma Tributária ativa para a Prefeitura de Ferraz de Vasconcelos/SP, o PDF (DANFSe) gerado pelo add-on não exibia o bloco "Tributação IBS/CBS" com os campos "Redução da Base de Cálculo", "Base de Cálculo Após Redução" e "Valor do Tributo" de cada linha (CBS, IBS UF, IBS Mun).
CorreçãoImplementado o cálculo da Redução da Base de Cálculo, da Base de Cálculo Após Redução e do Valor do Tributo de cada linha (CBS, IBS UF, IBS Mun), seguindo o modelo de referência apresentado pelo cliente. A correção foi estendida também aos demais municípios atendidos pelo mesmo provedor de software (Bebedouro/SP, Bragança Paulista/SP, Mococa/SP e Taboão da Serra/SP).
[NFS-e] [Prefeitura de Cariacica - ES] TAG's cLocIncid/xLocIncid em conflito agrupamento do ISS com agrupamento do IBS/CBS
[Todas as prefeituras]
Implementado(a) o campo de usuário "Mun. Incid. IBSCBS (Municipal)" na tela de nota fiscal de saída, permitindo informar a localidade de incidência do IBS/CBS separadamente do local de incidência/prestação do serviço, preenchido anteriormente apenas pelo campo TX_MunIncidNfse. O campo pode ser criado pelo botão "Criar Campos" no cadastro de entidade e está disponível para todas as prefeituras; quando não preenchido, o addon mantém o comportamento atual.
⚙Configuração: o novo campo precisa ser criado manualmente pelo botão "Criar Campos" na tela de cadastro de entidades, para as prefeituras que necessitarem informar a incidência do IBS/CBS separadamente do ISS.
TXPDE-8363Inclusão HOTFIX: 25/09/2026Correção
[NFS-e] [Prefeitura de Anchieta - ES] Aba "Autenticação" indisponível em parâmetros da NFS-e
[Prefeitura de Anchieta – ES]
ProblemaA aba "Autenticação" não estava disponível na tela de parâmetros da NFS-e ao cadastrar uma entidade com a prefeitura de Anchieta – ES, impedindo o preenchimento dos dados necessários para autorização das notas junto ao provedor E&L.
CorreçãoA aba "Autenticação" foi disponibilizada em parâmetros da NFS-e para o provedor E&L, permitindo o preenchimento do token de autorização das notas.
TXPDE-8356Inclusão HOTFIX: 25/09/2026Correção
[NFS-e] [Prefeitura de Cabedelo - PB] Campo data e hora do PDF divergente do enviado
[Prefeitura de Cabedelo – PB]
ProblemaA data e hora exibidas no PDF gerado pelo AddOn divergiam do PDF do portal nacional, pois o sistema buscava a data e hora da emissão da DPS em vez da data e hora da autorização do documento.
CorreçãoA geração do PDF para o município de Cabedelo – PB foi ajustada para buscar os dados a partir do XML autorizado, corrigindo a divergência com o PDF do portal nacional.
[NFS-e] [Provedor IPM] Enviar tag <endereco_informado> no XML de envio.
[Provedor IPM]
Corrigido(a) o envio da tag <endereco_informado> no XML de NFS-e para o provedor IPM, evitando a rejeição "00424 - Para o indicador de operação informado, o local de incidência do IBS/CBS deve ser igual ao local de estabelecimento do Tomador." quando o endereço do tomador informado é diferente do cadastrado na prefeitura. Foram criados campos de usuário na Nota Fiscal de Saída e no Parceiro de Negócios (com prioridade para o campo da nota) para controlar o envio da tag, que passa a ser enviada como <endereco_informado>1</endereco_informado> quando habilitada.
⚙Configuração: é necessário habilitar o parâmetro correspondente na tela de parâmetros gerais para ativar o envio da tag, criando o campo de usuário na Nota Fiscal de Saída e/ou no Parceiro de Negócios apenas para os clientes que necessitem.
Provedor GissOnline| Ordem das tags "CodigoObra" e "Art"
[Provedor GissOnline]
Problemano provedor GissOnline (diferente do GINFES), a ordem de geração das tags CodigoObra e Art no XML de envio saía invertida ao utilizar os campos de Código da Obra e ART, causando a rejeição "E160 Schema em desacordo consultar manual".
Correçãoajustada a geração do XML de envio do provedor GissOnline para informar os dados de obra na ordem correta, primeiro a tag CodigoObra e em seguida Art.
[NFS-e][Prefeitura de Bauru - SP] Incluir parâmetro "Usar Campo Customizado para Descrição dos Itens".
[Prefeitura de Bauru – SP]
Implementado(a) o parâmetro "Usar Campo Customizado para Descrição dos Itens", que permite exibir no DANFSe as descrições cadastradas nos itens da nota — reunidas e separadas por "|" — em vez da descrição do cabeçalho do serviço, para notas emitidas pelo padrão Nacional (ex.: Bauru/SP).
[NFS-e] [Bauru - SP] [Provedor SIL] Ajustar valor do ISS quando o imposto o ISS e calculado pelo add-on.
[Prefeitura de Bauru – SP]
ProblemaAo ativar o parâmetro de cálculo manual do ISS (criado no TXPDE-8109) para o provedor SIL, o documento passou a ser rejeitado, pois a base de cálculo do IBS/CBS não considerava o valor do ISS já ajustado pelo add-on. Após o ajuste da base de cálculo, foi identificada divergência nos valores do IBS/CBS gerados.
CorreçãoFoi adicionada a regra de cálculo manual da base de cálculo do IBS/CBS quando o parâmetro de cálculo manual do ISS estiver ativo e o provedor for SIL, descartando a base do CBS calculada pela fórmula padrão do imposto do SAP e calculando manualmente pela fórmula: Valor dos Serviços - Valor do ISS não retido - Valor do PIS não retido - Valor do COFINS não retido. Em seguida, o cálculo manual foi estendido para cada campo de valor do IBS/CBS na geração do XML do provedor SIL, eliminando a divergência identificada.
[NFS-e] [Provedor SIL] Considerar apenas retenções para compor o vTotTribFed
[Provedor SIL]
Corrigido(a) a composição do campo <vTotTribFed> ao usar o provedor SIL: agora são consideradas apenas as retenções para compor o valor do campo, tanto para sua visibilidade no XML (se zero, o campo é ocultado) quanto para seu valor, alinhando o comportamento ao layout do Emissor Nacional adotado pelo provedor e evitando rejeições em notas com impostos federais retidos.
Provedor Sil Tecnologia | Disponibilizar parâmetro "Usar cálculo manual para os valores do PIS/COFINS"
[Provedor Sil Tecnologia]
Implementado(a) parâmetro para o provedor Sil Tecnologia que permite o cálculo manual de todos os impostos retidos e não retidos, evitando divergências no valor líquido da nota e na base de cálculo do IBS/CBS que causavam rejeição pelo provedor.
[NFS-e][Prefeituras que utilizam schema da nacional] Envio das informações para Suspensão de exigibilidade do ISSQN
[Todas as prefeituras]
Corrigido o envio das informações de suspensão de exigibilidade do ISSQN (tags <tpSusp> e <nProcesso>) para prefeituras que utilizam o envio municipal com schema de XML nacional, funcionalidade anteriormente disponível apenas para o Ambiente Nacional. O PDF do documento também passou a exibir corretamente essas informações.
[NFS-e] [Prefeitura de Pedro Leopoldo - MG] Incluir parâmetro de não somar PIS e CONFINS junto ao CSLL.
[Prefeitura de Pedro Leopoldo – MG]
Corrigido(a) o envio de NFS-e ao provedor NFeCidades para a Prefeitura de Pedro Leopoldo – MG: os valores de PIS e COFINS retidos eram sempre somados ao valor da CSLL retida no documento enviado à prefeitura, sem opção de tratá-los separadamente, o que fazia o imposto destacado na nota divergir do valor apurado pelo contribuinte.
⚙Configuração: foi criado o parâmetro "Não somar PIS e COFINS retidos na CSLL", que permite à entidade optar por enviar apenas o valor da CSLL retida, sem somar PIS e COFINS.
[NFS-e] Homologação da prefeitura de Bueno Brandão - MG
[Prefeitura de Bueno Brandão – MG]
Homologado(a) a prefeitura de Bueno Brandão – MG. Durante o processo, foram identificadas e corrigidas particularidades técnicas de comunicação com a prefeitura (envio, consulta e cancelamento de notas), específicas desse município, sem impacto nos demais municípios já em produção. O cancelamento de notas fiscais foi desabilitado no sistema para esse município, pois a prefeitura não permite essa operação.
[NFS-e] Homologação da prefeitura de Vitória de Santo Antão - PE
[Prefeitura de Vitória de Santo Antão – PE]
Homologado(a) o envio e o cancelamento de NFS-e para a prefeitura de Vitória de Santo Antão – PE, via addon, seguindo o padrão Invent de envio (Tinus) com impressão via link. É necessário certificado digital, não sendo necessário informar frase secreta ou senha. O ambiente possui homologação, consulta de NFS-e por RPS e cancelamento; os campos Código de Serviço e Código da Atividade devem seguir a LC 116/2003 no formato 00.00.
TXPDE-8277Inclusão HOTFIX: 18/09/2026Correção
[NFS-e] [Nacional] Flag IBPT em percentual
[Ambiente Nacional]
ProblemaAo utilizar a flag "Usar alíquota para totais dos tributos" (percentual) do IBPT na NFS-e emitida pelo Ambiente Nacional, os valores de PIS e COFINS próprios não estavam sendo somados ao Total Federal, divergindo do comportamento já existente para o somatório por valor.
CorreçãoO somatório dos percentuais de tributos federais foi ajustado para contabilizar também o PIS e o COFINS não retidos, mantendo o mesmo comportamento já aplicado ao somatório por valor. Para evitar bi-tributação, quando há retenção de PIS ou COFINS, apenas o valor retido é considerado. Como o parâmetro do IBPT não é necessário na NFS-e emitida pelo Ambiente Nacional, o campo foi ocultado em tela quando utilizado o Emissor Nacional.
[NFS-e] [Provedor IMA] Atualização dos Links do WS que atende a reforma tributária
[Provedor IMA]
Implementada a atualização dos links de WebService (WS) do provedor IMA para atendimento à reforma tributária, contemplando os municípios de Campinas – SP, Campo Grande – MS, Sorocaba – SP, João Pessoa – PB, Teresina – PI e Belém – PA.
TXPDE-8235Inclusão HOTFIX: 14/09/2026Correção
[NFS-e][Prefeitura de Campinas - SP] Ajuste no envio do município do tomador estrangeiro.
[Prefeitura de Campinas – SP]
ProblemaAo gerar uma nota com tomador estrangeiro, o addon não criava a tag <CodigoMunicipio>.
CorreçãoAjustamos a geração de notas para tomador estrangeiro, somente para o município de Campinas, para incluir essa tag.
TXPDE-8233Inclusão HOTFIX: 14/09/2026Correção
[NFS-e] [Nacional] Campo de Optante do Simples Nacional ausente no PDF da DPS
[Ambiente Nacional]
ProblemaNo PDF da DPS/DANFSe de notas emitidas pelo padrão Nacional, o campo que indica a opção pelo Simples Nacional (MEI/ME-EPP) do prestador vinha ausente/vazio, mesmo quando a empresa era optante.
CorreçãoO campo passou a ser preenchido a partir do Regime Tributário geral da empresa (mesma configuração já usada corretamente pelo provedor SIL), de forma padronizada para todos os municípios do padrão Nacional.
TXPDE-8209Inclusão HOTFIX: 14/09/2026Correção
[NFS-e] [Prefeitura de Luziânia - GO] PDF Dados do prestador divergente do informado
[Prefeitura de Luziânia – GO]
ProblemaAo gerar o PDF (DANFSe) de uma nota fiscal de serviço eletrônica (NFS-e) para prestadores de Luziânia/GO, e de outros municípios que usam o mesmo modelo padrão nacional de nota, o sistema exibia o telefone do prestador de serviço incorreto no documento impresso.
CorreçãoO sistema passou a buscar o telefone no local correto dentro dos dados do prestador, garantindo que o número exibido no PDF seja o mesmo cadastrado para o prestador.
TXPDE-8205Inclusão HOTFIX: 14/09/2026Correção
[NFS-e] [Prefeitura de Rondonópolis - MT] Ajuste no envio da NFS-e para tomador estrangeiro emitida com tributação no municipio.
[Prefeitura de Rondonópolis – MT]
ProblemaAo emitir uma nota fiscal de serviço para tomador (cliente) do exterior, o sistema enviava o XML à prefeitura com informações obrigatórias ausentes e campos preenchidos de forma indevida, causando rejeição do documento pela Prefeitura de Rondonópolis - MT.
CorreçãoForam incluídos os campos ausentes e ajustado o envio dos campos que estavam vazios ou incorretos, adequando o XML ao formato exigido pela prefeitura para notas emitidas a tomadores estrangeiros.
TXPDE-8198Inclusão HOTFIX: 14/09/2026Correção
[NFS-e] [Prefeitura de São Paulo - SP] Erro/conflito entre as duas flags em parâmetros
[Prefeitura de São Paulo – SP]
ProblemaEm algumas notas de São Paulo, o sistema enviava um trecho do arquivo com endereço de imóvel em branco (CEP zerado, rua vazia), mesmo quando o usuário não havia preenchido nenhum imóvel — apenas o cadastro de Obra, que é uma tela diferente. Isso podia causar a rejeição da nota pela prefeitura.
Correçãoo sistema passou a verificar se existe realmente um imóvel preenchido antes de montar esse trecho do arquivo. Se não houver nada preenchido, essa parte deixa de ser enviada.
TXPDE-8224Inclusão HOTFIX: 11/09/2026Correção
[NFS-e] [Goiânia - GO] [NotaControl] Validar existência do intermediário para tipo de retenção do ISS
[Prefeitura de Goiânia – GO]
Problemao campo tpRetISSQN do schema da NotaControl não validava o parâmetro Ignorar Intermediário no XML, gerando o tipo 3 (Retido pelo Intermediário) sempre que havia intermediário, mesmo com o parâmetro ativo.
Correçãoajustado o preenchimento do campo tpRetISSQN para, quando o parâmetro Ignorar Intermediário estiver ativo, informar o tipo 2 (Retido pelo Tomador), independentemente de haver intermediário.
[NFS-e] [Goiânia - GO] [NotaControl] Atualizar o download de PDF via Link
[Prefeitura de Goiânia – GO]
Implementado(a) o envio do PDF da NFS-e por e-mail junto ao boleto, através do BankPlus, para o provedor NotaControl, em substituição ao download via link, que não pôde ser disponibilizado por restrição de permissão da Invent Software junto ao provedor.
[NFS-e][NotaControl] Disponibilizar o parâmetro de tomador sem endereço
[Provedor NotaControl]
Implementado(a) o parâmetro de tomador sem endereço para o provedor NotaControl.
TXPDE-8203Inclusão HOTFIX: 11/09/2026Correção
[NFS-e] Problema na definição de sequencial de documentos
[Todas as prefeituras]
ProblemaAo editar o sequencial de documentos pela tela de parâmetros gerais (aba "Sequências de Docs"), o add-on duplicava o registro quando a série também era editada, especialmente quando o registro mais atual não possuía série customizada — nesse caso, o parâmetro "Usar Série Customizada" deixava de ter efeito, sendo necessário apagar manualmente os registros da tabela SettingEntitySeqCodeInv para a entidade afetada. Também não eram removidas as séries desmarcadas até o fechamento da tela de parâmetros gerais. Além disso, ao adicionar a Doc, a seleção da série a utilizar considerava apenas a primeira sequência encontrada para a entidade, podendo escolher a série errada quando havia mais de uma sequência cadastrada para a mesma entidade.
CorreçãoCorrigida a manutenção da tabela de sequências de documentos, de forma que apenas as sequências marcadas e a série customizada preenchida em tela sejam mantidas, eliminando a duplicidade de registros. Também foi corrigida a seleção da série ao adicionar a Doc: agora a busca considera tanto a entidade quanto a sequência da nota, e não apenas a entidade, evitando escolher uma série incorreta quando a entidade possui mais de uma sequência definida.
⚙️ Observação: Caso já existam registros duplicados na tabela SettingEntitySeqCodeInv (decorrentes do problema anterior), será necessário removê-los manualmente.
TXPDE-8202Inclusão HOTFIX: 11/09/2026Correção
[NFS-e] O campo da alíquota do Simples Nacional não está funcionando para prefeituras / provedores que usam o layout da NFS-e Nacional
[Ambiente Nacional]
ProblemaO parâmetro e o campo da alíquota do Simples Nacional não estavam funcionando para as prefeituras, provedores e para o Emissor Nacional que utilizam o layout da NFS-e Nacional — o valor informado não substituía a alíquota de ISS da nota do SAP, como já ocorria corretamente fora desse layout.
CorreçãoCorrigida a aplicação da alíquota de ISS do Simples Nacional na emissão via Emissor Nacional.
TXPDE-8199Inclusão HOTFIX: 11/09/2026Correção
[NFS-e] [Prefeitura de Rondonópolis - MT] API retorna mensagem "Sucesso" em vez do arquivo PDF
[Prefeitura de Rondonópolis – MT]
ProblemaAo consultar o PDF de notas do município de Rondonópolis – MT pela API /api/v2/PRODUCAO/invent/docs/consultar/pdf, a API retornava a mensagem "Sucesso" em vez do arquivo PDF, pois o add-on estava configurado para servir o PDF desse município via link.
CorreçãoA visualização do PDF via link para o município passou a ser controlada por parâmetro; quando não utilizado, é possível consultar normalmente o PDF das notas desse município pela API v2.
Goiânia - GO | Divergência nos valores de PIS e COFINS
[Provedor NotaControl]
Corrigido(a) divergência no cálculo de PIS/COFINS na emissão de NFSe, que causava a rejeição "Erro 60694: O valor do PIS informado não corresponde ao resultado da BC PIS/COFINS × Alíquota PIS, informados na DPS". Foi disponibilizado um parâmetro de cálculo manual de PIS/COFINS, movido para a aba "Parâmetros", visível para o emissor nacional e para o provedor NotaControl.
⚙Configuração: é necessário habilitar o parâmetro de cálculo manual de PIS/COFINS, disponível na aba "Parâmetros", para utilizar o novo comportamento.
TXPDE-8193Inclusão HOTFIX: 09/09/2026Correção
[NFS-e][Prefeitura de Vinhedo - SP] Gerar a tag codObra no grupo de item
[Prefeitura de Vinhedo – SP]
ProblemaO add-on estava gerando a tag codObra dentro do grupo dadosServico e gerando a tag descricaoObra, enquanto a prefeitura de Vinhedo – SP espera as tags codObra e descricao dentro do grupo item.
CorreçãoA tag codObra foi movida para o grupo item.
TXPDE-8099Inclusão HOTFIX: 09/09/2026Correção
[NFS-e] [Prefeitura de São Francisco do Sul - SC] Ajuste no preenchimento das situações tributarias.
[Prefeitura de São Francisco do Sul – SC]
ProblemaPara o envio da NFS-e com retenção, o add-on utilizava um processo específico do TaxPlus para montar a tag situacao_tributaria a partir de um campo de usuário do PN (U_TX_IndNat) também utilizado por outros processos, o que gerava receio no cliente em usar a funcionalidade e conflito de estrutura com outros projetos.
CorreçãoRemovido o processo específico do TaxPlus e ajustada a montagem da tag situacao_tributaria para utilizar o mesmo processo já aplicado no município de Pinhais – PR, passando a obter a informação de ISS retido diretamente do documento no SAP, em vez de depender do campo de usuário compartilhado.
Prefeitura de Olinda - PE | Informações Complementares da NFSe
[Prefeitura de Olinda – PE]
Implementado(a) o envio de informações complementares no RPS para a Prefeitura de Olinda – PE, através da tag OutrasInformacoes, conforme orientação do provedor. O conteúdo é retornado corretamente na tag xInfComp do XML autorizado, e o add-on passa a gerar o PDF da NFSe já contemplando essa informação.
[NFS-e][Prefeitura de Santos - SP] Abrindo RPS ao visualizar impressão no documento de saída.
[Prefeitura de Santos – SP]
Implementado(a) o comportamento dos botões de visualizar e exportar PDF da NFS-e: quando nenhuma opção específica (RPS ou NFS-e) é selecionada, o PDF exibido passa a ser definido pelo status do documento, sendo PDF da NFS-e (com tarja de cancelamento quando aplicável) para os status Autorizado, Cancelado ou Cancelamento Rejeitado, e PDF do RPS para os demais status. Os textos dos botões Transmitir/Retransmitir, Visualizar Impressão e Exportar para PDF foram renomeados para (Re)Transmitir, Visualizar PDF e Exportar PDF, respectivamente, e as mensagens de aviso de exportação foram atualizadas para melhor refletir o comportamento.
Adequação do codigo municipio para os provedores IMA/DSF 2.0
[Provedores IMA e DSF 2.0]
Corrigido(a) o envio da tag <CodigoMunicipio> com valor zerado para tomadores estrangeiros nos provedores IMA e DSF 2.0, evitando a rejeição "Erro E60: Município do tomador do serviço não encontrado" retornada pelos provedores. Para tomador nacional, o comportamento de envio do código IBGE do município é mantido inalterado.
[NFS-e] Melhorar mensagens de erro ao tentar obter os dados da nota do SAP
[Todas as prefeituras]
Implementada(a) melhoria nas mensagens de erro exibidas ao tentar obter os dados da nota do SAP: quando os campos cClassTrib/CST estão vazios ou mal configurados no ambiente do cliente, a mensagem agora indica de forma mais específica em qual método ocorreu a falha (ex.: ObterTributosIbsCbs), facilitando a identificação de problemas de parametrização.
TXPDE-8187Inclusão HOTFIX: 04/09/2026Correção
[NFS-e] [Nacional] Sequencial customizado de RPS não está sendo respeitado quando altera manualmente no FollowUp
[Ambiente Nacional]
Problemaao alterar manualmente o sequencial customizado de RPS pela tela de FollowUp em notas emitidas pelo Ambiente Nacional, o parâmetro "Último RPS" da entidade não era atualizado com o novo valor definido, fazendo com que a próxima nota emitida usasse um sequencial baseado no valor antigo em vez do informado no FollowUp.
Correçãoo sequencial do RPS informado no FollowUp agora é corretamente salvo no parâmetro "Último RPS" da entidade para o emissor Nacional, garantindo que a próxima nota seja gerada com o sequencial esperado.
[NFS-e] [Provedor NotaControl] Incluir o provedor no parâmetro de não somar PIS/COFINS retidos na CSLL
[Provedor NotaControl]
Corrigido(a) a interferência da regra que impede a soma de PIS/COFINS retidos na CSLL para o provedor NotaControl, que estava afetando indevidamente notas emitidas diretamente pelo Emissor Nacional (NT 007), como no caso de Goiânia em homologação. Foi incluído um parâmetro específico para o provedor, de forma que a regra não interfira mais nas emissões feitas pelo Emissor Nacional.
GissOnline e Ginfes | Criar parâmetro "Não somar PIS/COFINS retidos no CSLL"
[Provedor GissOnline e Ginfes]
Implementado(a) parâmetro para definir se os valores retidos de PIS, COFINS e CSLL devem ser considerados no cálculo do valor líquido da NFSe, para os provedores GissOnline e Ginfes, atendendo às regras da NT 007. Com o parâmetro marcado, o campo <ValorPis> recebe o valor do PIS retido (ou o da linha, quando não houver retenção), o <ValorCofins> recebe o valor do COFINS retido (ou o da linha) e o <ValorCsll> recebe apenas o valor do CSLL retido. Com o parâmetro desmarcado, <ValorPis> e <ValorCofins> ficam zerados e o <ValorCsll> passa a somar os valores retidos de PIS, COFINS e CSLL.
⚙Configuração: é necessário habilitar o parâmetro na aba "Parâmetros" para aplicar o novo comportamento de cálculo.
Provedor IPM | Quando flag da reforma está desmarcada XML de envio dá erro
[Provedor IPM]
ProblemaAo enviar uma nota fiscal com o parâmetro Considerar reforma desabilitado, o addon gerava um erro de referência de objeto não definida ao obter o XML de envio.
CorreçãoAdicionada validação para verificar se os dados da reforma estão preenchidos e o parâmetro está habilitado; caso contrário, a nota é enviada sem esses dados.
TXPDE-8103Inclusão HOTFIX: 04/09/2026Correção
[NFS-e] [Prefeitura de Goiânia - GO] Add-on considerado configuração do nacional quando alterado para o envio municipal.
[Prefeitura de Goiânia – GO]
ProblemaAo habilitar o envio nacional para este provedor, o complemento passava a utilizar o mesmo conversor/montador de XML do provedor nacional e, consequentemente, os mesmos parâmetros da entidade nacional, mesmo após selecionar o envio municipal — fazendo com que a IM não fosse enviada e causando rejeição na emissão.
CorreçãoAo selecionar o provedor municipal, o complemento passa a utilizar os parâmetros da entidade municipal para montar o XML.
TXPDE-8101Inclusão HOTFIX: 04/09/2026Correção
[NFS-e] [Prefeitura de Porto Belo - SC] Ajuste nas tags de imóvel no XML quando retirado o endereço.
[Prefeitura de Porto Belo – SC]
Problemaao remover o endereço do imóvel, as tags de endereço permaneciam vazias no XML enviado, causando rejeição do documento.
Correçãoajustada a validação do endereço do imóvel para gerar as tags somente quando houver o preenchimento completo dos campos obrigatórios, conforme a NT004 v2.0 (SE/CGNFS-e), evitando tags vazias e rejeições da nota fiscal.
TXPDE-8078Inclusão HOTFIX: 04/09/2026Correção
[NFS-e] [Prefeitura de Novo Hamburgo - RS] Ao tentar retirar o PDF não localiza [NovoHamburgoRs.frx]
[Prefeitura de Novo Hamburgo – RS]
ProblemaAo tentar gerar o PDF da NFS-e, o sistema não localizava o arquivo de layout, retornando a mensagem "Não foi encontrado arquivo com o nome [NovoHamburgoRs.frx]", mesmo ao tentar recriar o documento.
CorreçãoAlterada a geração do PDF do provedor para utilizar o DANFSe 2.0 da NFS-e Nacional.
TXPDE-8059Inclusão HOTFIX: 04/09/2026Correção
[NFS-e] [Prefeitura de Cruzeiro do Sul- AC] Leitura do retorno da prefeitura quando é status de Rejeição
[Prefeitura de Cruzeiro do Sul – AC]
Problemaquando a prefeitura retornava uma rejeição, o status do documento não era atualizado nem exibido na tela da NFS-e ou no Follow-up, ficando o cliente sem saber o motivo da rejeição.
Correçãoimplementada a leitura do arquivo de retorno da prefeitura, tratando a mensagem de erro para exibição na tela de Log do Follow-up.
TXPDE-8050Inclusão HOTFIX: 04/09/2026Correção
[NFS-e][Prefeitura de São Bernardo do Campo - SP] Ajuste no retorno de autorização e consulta de RPS.
[Prefeitura de São Bernardo do Campo – SP]
ProblemaO XML de retorno de autorização e de consulta por RPS era lido incorretamente pelo add-on, fazendo com que documentos já autorizados na prefeitura ficassem marcados como rejeitados.
CorreçãoAjustada a leitura do XML de retorno de autorização e de consulta por RPS.
TXPDE-8044Inclusão HOTFIX: 04/09/2026Correção
[NFS-e] [Rio de Janeiro - RJ] Erro na Leitura de PDF Municipal após atualização para nacional
[Prefeitura do Rio de Janeiro – RJ]
Problemaapós a migração do município do ambiente municipal para o nacional, a visualização/impressão do PDF de NFS-e emitidas anteriormente (padrão municipal) apresentava erro de comunicador não encontrado, gerando um PDF em branco sem valor fiscal.
Correçãoajustado o add-on para emitir/exibir o PDF no modelo DANFSe 2.0 nacional para os municípios que migraram para o ambiente nacional.
TXPDE-8035Inclusão HOTFIX: 04/09/2026Correção
[NFS-e] [Prefeitura de Goiânia - GO] Ajuste no envio do endereço do imovel.
[Prefeitura de Goiânia – GO]
Problemaao emitir NFS-e com a tag de imóvel preenchida, o XML de envio não destacava que o endereço informado era nacional, o que causava rejeição do documento pela prefeitura.
Correçãocriado um novo layout de XML para o provedor NotaControl com a tag de destaque de endereço nacional, permitindo a autorização correta da nota tanto com quanto sem o grupo imóvel.
[NFS-e] [Ambiente Nacional] Criar coluna de alíquota do SAP e alíquota do XML autorizado no follow-up
[Ambiente Nacional]
Implementadas duas novas colunas no follow-up do NFS-e para comparar a alíquota de ISS lançada no SAP com a retornada pelo Emissor Nacional após a autorização da nota: "Alíquota ISS SAP" (campo AliquotaIssSap na tabela Doc, com a alíquota de ISS informada no SAP, priorizando o ISS Retido) e "Alíquota ISS NFSe Nacional" (campo AliquotaIssNfseNacional na tabela Doc, com a alíquota retornada na tag <pAliqAplic> do XML autorizado pelo Emissor Nacional). Os campos são preenchidos automaticamente após a autorização da nota, permitindo ao cliente montar relatórios para identificar divergências entre as alíquotas.
TXPDE-7754Inclusão HOTFIX: 04/09/2026Correção
[NFS-e] [Prefeitura de Caxias do Sul - RS] Rejeição código do país somente quando é China
[Prefeitura de Caxias do Sul – RS e Carlos Barbosa – RS / Provedor Infisc]
ProblemaO XML enviado à prefeitura apresentava a descrição do país do tomador estrangeiro sem os acentos, vírgula e demais caracteres especiais corretos (ex.: "China Republica Popular da" em vez de "China, República Popular da"), fazendo com que a prefeitura rejeitasse a nota por o nome do país não corresponder ao código do país informado — bloqueando o faturamento para tomadores estrangeiros como China.
CorreçãoCorrigida a montagem da descrição do país do tomador no XML, removendo a remoção indevida de acentos, vírgulas e demais caracteres especiais desse campo, passando a enviá-la exatamente como esperado pela prefeitura. O ajuste foi aplicado para todos os municípios atendidos pelo provedor Infisc (incluindo Caxias do Sul – RS e Carlos Barbosa – RS), evitando a rejeição de notas fiscais para tomadores estrangeiros como "China, República Popular da".
TXPDE-8157Inclusão HOTFIX: 03/09/2026Correção
[NFS-e] [Prefeitura de Tangará da Serra- MT] Leitura do retorno da prefeitura quando é status de Autorizado
[Prefeitura de Tangará da Serra – MT]
ProblemaQuando o retorno da prefeitura de Tangará da Serra – MT indicava status de Autorizado, o status do documento não era atualizado na tela da NFSe nem no Follow-up, permanecendo como não informado.
CorreçãoAjustada a leitura do XML de retorno da Prefeitura de Tangará da Serra – MT, incluindo a nota no add-on de acordo com o status retornado.
[NFS-e][Todas as prefeituras] Criar histórico para que seja mostrado o user que recriou o PDF.
[Todas as prefeituras]
Implementado(a) registro de histórico na DocHist para NFS-e, informando o usuário responsável pela solicitação de alteração e pela execução do processo de recriação do DANFSe (coluna RecriarDanfse), permitindo identificar quem realizou cada etapa.
TXPDE-8038Inclusão HOTFIX: 27/08/2026Correção
Provedor GissOnline | Valor era muito grande ou muito pequeno para Int32
[Provedor GissOnline]
ProblemaAo gerar o XML para o provedor GissOnline, ocorria o erro "Valor era muito grande ou muito pequeno para Int32" quando o campo CNAE não estava preenchido na entidade.
CorreçãoAlterado o tipo do campo CNAE na entidade e nos campos relacionados, permitindo a geração do XML do provedor GissOnline sem a necessidade de preenchimento do CNAE.
TXPDE-8036Inclusão HOTFIX: 27/08/2026Correção
Problema na criação das procedures ao iniciar os add-ons dos Docs Eletrônicos
[Todas as prefeituras]
ProblemaAo iniciar os add-ons dos Documentos Eletrônicos na versão 26.7.31.425, ocorriam erros de procedures invalidadas (ex.: sp_GetMovimento) devido à separação do módulo Fiscal no código-fonte do add-on, impactando a Análise de Movimento Fiscal em bancos SAP HANA.
CorreçãoCorrigidos os scripts de verificação/atualização de schema para garantir a criação e a persistência correta das procedures do TaxPlus Fiscal nesta hotfix.
[NFS-e] [São Bernardo do Campo - SP] Formato da tag <Aliquota>
[Prefeitura de São Bernardo do Campo – SP]
Corrigido(a) o formato de geração da tag <Aliquota>, que estava sendo enviada no padrão 5,00 ao invés de 0,05, causando rejeição do documento pela prefeitura quando havia tributação de ISS.
[NFS-e] Omitir botão "Infos Adicionais" na tela da NFSe no SAP enquanto estiver comunicando com a prefeitura / Emissor Nacional
[Todas as prefeituras]
Implementado(a) a ocultação do botão "Infos Adicionais" na tela da NFSe enquanto o complemento estiver comunicando com a prefeitura ou o Emissor Nacional para autorizar ou cancelar a nota, seguindo o mesmo comportamento já aplicado aos demais campos.
[NFS-e] [Prefeitura de Rio das Ostras - RJ] Atualização no WebService
[Provedor Tiplan]
Implementado(a) o envio de NFS-e via WebService Nacional (API) do provedor Tiplan, em substituição ao WebService antigo, contemplando municípios atendidos por esse provedor (ex.: Rio das Ostras/RJ, Macaé/RJ e Americana/SP).
[NFS-e][Todas as prefeituras] Permitir exportar todo histórico do documento via followup
[Todas as prefeituras]
Implementada, na tela de Follow-up, a opção de exportar o histórico completo do documento (rejeições, processos internos como cancelamento e geração de PDF/e-mail) para um arquivo Excel, facilitando a análise de suporte.
[NFS-e] [Prefeitura de Praia Grande - SP] Erro tag <p1:Art> sendo gerada sem valor
[Prefeitura de Praia Grande – SP]
ProblemaAo emitir NFS-e para a Prefeitura de Praia Grande – SP, a tag <p1:Art> era gerada sem valor mesmo quando o código da obra não estava preenchido, causando a rejeição "E160 – Arquivo em desacordo com o XML Schema" e impedindo a emissão do documento.
CorreçãoCorrigido para que as tags <Art> e <CodigoObra> sejam geradas de forma independente, cada uma somente quando possuir valor preenchido.
TXPDE-7993Inclusão HOTFIX: 25/08/2026Correção
[NFS-e] [Santo André - SP] Formato da tag <Aliquota>
[Prefeitura de Santo André – SP]
ProblemaNa emissão de NFS-e para o município de Santo André – SP (emissão GINFES), havendo tributação de ISS, a tag <Aliquota> era gerada em formato incorreto (ex.: "3.00" em vez de "0.03"), causando a rejeição "Campo AliquotaServicos informado incorretamente" e impedindo a emissão do documento.
CorreçãoCorrigido o formato de geração da tag <Aliquota> para o município de Santo André – SP, passando a ser gerada corretamente no padrão decimal esperado (ex.: 0.03 para 3%).
Provedor IPM | Atualização Layout Reforma - Retornando Rejeição Erro 00417 - Obrigatório informar local de Incidência IBS/CBS
[Provedor IPM]
Corrigido(a) a rejeição retornada pelo provedor IPM (Erro 00417 – Obrigatório informar local de Incidência IBS/CBS) na emissão de NFSe, ajustando o XML de envio para incluir o preenchimento da tag <cLocalidadeIncid> do grupo IBSCBS.
TXPDE-8001Inclusão HOTFIX: 24/08/2026Correção
[NFS-e][Prefeitura de Osasco - SP] PDF e RPS gerado sem logo.
[Prefeitura de Osasco – SP]
Problemao PDF e o RPS eram gerados sem a logo informada nos parâmetros gerais do add-on.
Correçãoo PDF passou a ser gerado a partir do DANFSe 2.0 do Emissor Nacional, obtendo os dados a partir do XML autorizado, atendendo à NT 008 da NFS-e Nacional.
TXPDE-7968Inclusão HOTFIX: 24/08/2026Correção
[NFS-e] [Prefeitura de Ribeirão Preto - SP] Não somar PIS/COFINS na tag CSLL
[Prefeitura de Ribeirão Preto – SP]
Problemaos valores retidos de PIS/COFINS estavam sendo somados novamente na tag vRetCSLL, distorcendo o valor líquido informado no XML de envio.
Correçãoo envio para este provedor deixou de somar os valores de PIS/COFINS na tag da CSLL.
[NFS-e] [Provedor NotaControl] Disponibilizar parâmetro de sequencial de lote
[Provedor NotaControl]
Corrigido(a) o parâmetro de sequencial de lote que, mesmo habilitado, gerava numeração de lote com mais de 10 dígitos no XML de envio, causando a rejeição "E160 – Arquivo em desacordo com o XML Schema" e impedindo o faturamento.
TXPDE-7877Inclusão HOTFIX: 20/08/2026Correção
[NFS-e] [Prefeitura de Canoas- RS] Recriação do PDF não está funcionando corretamente
[Prefeitura de Canoas – RS]
ProblemaAo solicitar a recriação do PDF (DANFSe) via serviço, mesmo apagando o arquivo existente, o sistema registrava o log de recriação normalmente, porém o novo arquivo não era gerado na pasta correspondente.
CorreçãoAjustado o fluxo de geração do PDF utilizado pela opção de recriação de DANFSe via serviço, garantindo que o arquivo seja efetivamente criado, tanto sobre um PDF já existente quanto após sua exclusão.
[NFS-e][Prefeitura de Bauru - SP] Enviar valores de IBS e CBS no XML de envio
[Prefeitura de Bauru – SP]
Implementado(a) o envio dos valores de IBS e CBS no XML da NFS-e, por meio do preenchimento do grupo IBSCBS do cabeçalho, conforme o novo layout divulgado pela prefeitura.
[NFS-e] [Provedor IMA] Adequação a reforma tributaria (ambiente de homologação)
[Provedor IMA]
Implementada a emissão de NFS-e via Ambiente Nacional (Reforma Tributária) para os municípios atendidos pelo provedor IMA (Belém – PA, Campinas – SP, Campo Grande – MS, João Pessoa – PB, São José dos Campos – SP, Sorocaba – SP e Teresina – PI), utilizando o novo WebService disponibilizado pelo provedor — sem exigência de frase secreta/senha, com certificado digital, consulta de NFS-e por Número (apenas notas autorizadas, sem consulta por RPS) e cancelamento (URL ainda não divulgada pelo provedor). O campo Item da LC 116 deve ser informado com o código de tributação nacional (6 dígitos) e o Código de Tributação com o código municipal (3 dígitos). A implementação foi validada somente em ambiente de homologação — as URLs de produção ainda não foram divulgadas pelo provedor, e a tarefa permanece como "Desenvolvido" até a confirmação completa do novo WebService.
[NFS-e][Prefeitura de Anápolis - GO] Opção em Parâmetros para síncrono e assíncrono
[Prefeitura de Anápolis – GO]
ProblemaApós a atualização do município para a Reforma Tributária, todos os documentos passaram a retornar a mensagem "envio assíncrono não está disponível para notas da Reforma Tributária", forçando o uso exclusivo do envio síncrono e paralisando o faturamento.
CorreçãoRestaurada a parametrização do município, voltando a permitir a opção de envio síncrono ou assíncrono na tela de Parâmetros.
[NFS-e] [Fortaleza - CE] Atualização de layout com campos referentes a PIS/COFINS
[Prefeitura de Fortaleza – CE]
Implementado(a) o layout de emissão da NFS-e do município de Fortaleza – CE, com a inclusão dos campos TipoRetencaoPisCofins, TipoCstPisCofins e BaseCalculoPisCofins, referentes ao PIS/COFINS, evitando a rejeição de notas que o município passou a aplicar devido à ausência desses campos no novo schema.
TXPDE-7919Inclusão HOTFIX: 17/08/2026Correção
[NFS-e] [Prefeitura de Fortaleza - CE] Ao incluir natureza da operação "10-Não tributável" no XML de envio puxa 7 e tag <CodigoMunicipio> fica zerada
[Prefeitura de Fortaleza – CE]
ProblemaAo selecionar a natureza da operação "Não tributável" e deixar o local de prestação vazio, o addon atribuía o valor 0 à tag <CodigoMunicipio>.
CorreçãoAjustamos o esquema de envio do XML para que, quando o local de prestação estiver vazio, o addon atribua à tag <CodigoMunicipio> o código do município do prestador.
[Provedor Infisc]
Implementado(a) parâmetro para incluir o número do lote no nome do arquivo PDF de NFSe, evitando conflito quando o provedor autoriza notas do mesmo prestador com número repetido. O nome do arquivo passa a seguir o padrão NFSE_lote_numero (ex.: NFSE_33134092923_186342.pdf).
⚙Configuração: É necessário criar manualmente o campo IncluirLoteNoNomeDoPdf (tipo BIT, nullable) na tabela SettingEntityEnv e habilitá-lo (valor 1) para ativar a inclusão do número do lote no nome do PDF.
[NFS-e] [Nacional] Trocar preenchimento do campo <verAplic> no XML DPS pelo número da versão do add-on
[Ambiente Nacional]
Implementado(a) a alteração do preenchimento do campo <verAplic> no XML DPS, que passou a exibir o número da versão do add-on (por exemplo, NFSe_25.12.30.53022), em substituição ao valor fixo anterior, para melhorar a rastreabilidade dos XMLs gerados por ticket de atendimento.
TXPDE-7925Inclusão HOTFIX: 14/08/2026Correção
[NFS-e] [Prefeitura de Belém - PA] ISS não retido saindo no PDF do AddOn como ISS retido
[Prefeitura de Belém – PA]
ProblemaO PDF do AddOn exibia a retenção do ISSQN como "Retido" quando a nota fiscal estava configurada como "Não Retido", causando divergência em relação ao PDF disponibilizado pela prefeitura.
CorreçãoFoi realizado ajuste na validação do status do ISSQN (Retido e Não Retido), garantindo que as retenções sejam exibidas corretamente de acordo com a condição da nota fiscal.
TXPDE-7835Inclusão HOTFIX: 14/08/2026Correção
[NFS-e] [Prefeitura de Osasco - SP] Está removendo caractere especial da tag <Cidade> e está gerando rejeição
[Prefeitura de Osasco – SP]
Problemaao emitir NFS-e para município com apóstrofo ou caractere especial no nome (ex.: Sant'Ana do Livramento), o caractere era removido da tag <Cidade> durante a montagem do XML de envio, gerando rejeição com a mensagem "Município informado (SantAna do Livramento) é diferente do município relacionado ao código 4317103. Por favor, consulte a lista de municípios e códigos do IBGE (método RTC_ConsultarMunicipio)."
Correçãorealizado ajuste para preservar os acentos e caracteres especiais na descrição da cidade, impedindo sua remoção durante a montagem das informações.
[NFS-e][Prefeitura de Brasília - DF] Alteração do link do WS.
[Prefeitura de Brasília – DF]
Implementada a atualização do link do Web Service (WS) de emissão de NFS-e para o município de Brasília – DF, cujo portal foi alterado pela prefeitura.
Prefeitura de Marília - SP | "Erro ao ler retorno da prefeitura, segue descrição completa" - Retorno com valores zerados
[Prefeitura de Marília – SP]
Implementado(a) ajuste no fluxo de autorização de NFSe na Prefeitura de Marília – SP para contornar a demora no retorno da consulta da nota (consultar_nota_prestador_retorno), decorrente da necessidade de aguardar a sincronização com o ADN. O add-on agora grava o número da nota na Doc assim que recebe o retorno da emissão (gerar_nota_retorno), permitindo a consulta assim que a sincronização for concluída.
⚙Configuração: recomenda-se ajustar o parâmetro TaxPlus NFS-e | Parâmetros Gerais | Dados Gerais – Gerais (1) | “Consultar o status do lote na prefeitura depois de __ minutos” para 2 minutos, pois nos testes realizados a sincronização da NFSe com o ADN levou cerca de 1min30s.
TXPDE-7848Inclusão HOTFIX: 13/08/2026Correção
[NFS-e][Prefeitura de São Paulo - SP] Ajustar a visualização do PDF pelo documento de saída.
[Prefeitura de São Paulo – SP]
ProblemaO documento era autorizado sem erros, porém o PDF não era exibido ao clicar em visualizar o PDF pela tela de documento de saída. Os processos de visualizar o RPS, exportar o PDF e exportar o RPS funcionavam normalmente; apenas a visualização do PDF pelo documento de saída ficava travada, sem abrir.
CorreçãoAjustada a visualização e exportação do PDF (NFS-e/RPS) na tela de documento de saída.
TXPDE-7831Inclusão HOTFIX: 13/08/2026Correção
[NFS-e][Prefeitura de Barueri - SP][TXT] Ajustar o envio TXT para enviar conforme a reforma tributaria.
[Prefeitura de Barueri – SP]
Problemao provedor atualizou o esquema de envio; o formato XML passou a usar a versão nova da reforma tributária, mas o envio via TXT continuou utilizando o esquema antigo, fazendo com que os documentos fossem gerados sem os dados da reforma e rejeitados pela prefeitura.
Correçãoo envio via TXT foi ajustado para utilizar o mesmo esquema do envio via XML, garantindo que futuras atualizações do esquema no addon sejam aplicadas a ambos os formatos.
[NFS-e] [Provedor Infisc] Incluir geração de PDF usando a DANFSe 2.0
[Provedor Infisc]
Implementada a geração do PDF utilizando exclusivamente a DANFSe 2.0 da NFSe Nacional para o provedor Infisc, cuja adoção do novo layout havia sido adiada pelo provedor mesmo após a vigência obrigatória.
TXPDE-7845Inclusão HOTFIX: 12/08/2026Correção
[NFS-e] [Prefeitura de Eusebio - CE] Quebra de linha quando desmarcado flag da reforma em parâmetros gerais
[Prefeitura de Eusébio – CE]
ProblemaQuando a nota era emitida sem a flag da reforma marcada em parâmetros gerais, a quebra de linha não era obedecida, gerando divergência entre o valor informado no SAP e o conteúdo gerado no PDF e no XML de envio.
CorreçãoAdicionada a quebra de linha para os casos em que a flag da reforma estiver desmarcada.
TXPDE-7847Inclusão HOTFIX: 11/08/2026Correção
[NFS-e][Prefeitura de São Bernardo do Campo - SP][1.0] Ajuste no envio da NFS-e com ISS retido.
[Prefeitura de São Bernardo do Campo – SP]
ProblemaAo emitir NFS-e com ISS retido, o complemento não enviava a alíquota do serviço na tag Aliquota e, em determinadas versões, enviava simultaneamente as tags ValorIss e ValorIssRetido, causando rejeição no envio.
CorreçãoAjustada a geração do XML para garantir o envio da tag Aliquota. A tag ValorIss passa a ser gerada apenas quando a tag ValorIssRetido não estiver presente, evitando o envio simultâneo das duas informações.
TXPDE-7836Inclusão HOTFIX: 11/08/2026Correção
[NFS-e] [Prefeitura de Ipatinga - MG] Gerando PDF sem informações
[Prefeitura de Ipatinga – MG]
ProblemaO PDF autorizado da NFS-e era gerado sem as informações da nota para a Prefeitura de Ipatinga – MG.
CorreçãoCorrigido o tratamento para os casos em que o envio síncrono retorna um retorno assíncrono da prefeitura, passando a ser tratado como nota ainda aguardando retorno. O PDF passou a utilizar o DANFSe 2.0 da NFSe Nacional, e a chave utilizada na nota passou a ser a da NFSe Nacional.
[NFS-e] Mover parâmetro de "Ignorar intermediário no XML de envio" para a aba "Parâmetros"
[Prefeitura de Braço do Norte – SC e Joinville – SC]
Implementado(a) o reposicionamento do parâmetro "Ignorar intermediário no XML de envio" da aba "Gerais" para a aba "Parâmetros", tornando-o disponível também para o emissor nacional. Essa mudança restabelece o funcionamento correto do parâmetro para o município de Joinville – SC, que passou a emitir pelo emissor nacional.
⚙Configuração: Para o município de Joinville – SC, o cliente precisa desmarcar o emissor nacional, marcar o parâmetro "Ignorar intermediário no XML de envio" e marcar novamente o emissor nacional para que a alteração tenha efeito.
Provedor NfeCidades | Atualizar layout conforme NT 007 - TpRetPisCofins
[Provedor NfeCidades]
Corrigido o cálculo dos valores e impostos da NFS-e no provedor NfeCidades, que passou a reutilizar a mesma lógica do Emissor Nacional: os campos CST e tpRetPisCofins agora usam o conversor do Emissor Nacional, e os valores de ISS, CSLL, IRRF, INSS, PIS e COFINS passam a ser obtidos a partir dos campos de retido/não retido do modelo Nacional. O ajuste elimina a rejeição GOV13 relacionada ao domínio de valores aceitos pela tag tpRetPisCofins, identificada ao emitir para o município de Poços de Caldas – MG.
Observação: o provedor está deduzindo os valores de PIS e COFINS não retidos do valor líquido da NFS-e; recomenda-se prestador entrar em contato com a prefeitura/provedor para adequação conforme a NT 007.
TXPDE-7834Inclusão HOTFIX: 10/08/2026Correção
[NFS-e][Prefeitura de Fortaleza - CE] Ajuste no PDF gerado pelo add-on
[Prefeitura de Fortaleza – CE]
ProblemaAo ler o arquivo de retorno da NFS-e, o add-on não salvava a chave de acesso no parâmetro de chave de cancelamento, exibindo a chave municipal (em vez da chave de acesso correta) tanto no cabeçalho quanto no rodapé do relatório em PDF.
CorreçãoO add-on foi ajustado para obter o valor a partir da tag <ChaveAcesso> do arquivo de retorno e gravá-lo corretamente no parâmetro de chave de cancelamento, exibindo-o de forma correta no relatório PDF.
TXPDE-7829Inclusão HOTFIX: 10/08/2026Correção
[NFS-e][Prefeitura de Caxias do Sul - RS] Não enviar ISS normal quando houver ISS retido.
[Prefeitura de Caxias do Sul – RS]
Problemaao emitir a NFS-e com ISS retido, o cliente recebia a rejeição "E34390 - NFS-e não pode contem itens com situações tributárias distintas", pois o XML enviava simultaneamente as tags de ISS retido e de ISS normal, mesmo quando os valores deveriam ser preenchidos apenas no grupo de ISS retido (ISSST).
Correçãoajustada a montagem do XML das tags de ISS Retido e ISS Não Retido, de forma que, quando o ISS for retido, as tags de ISS não retido não sejam mais montadas no XML, eliminando a rejeição.
TXPDE-7826Inclusão HOTFIX: 10/08/2026Correção
[NFS-e] [Prefeitura de Bauru - SP] TAG <vLiq> não está removendo retenções e preenchendo valor cheio
[Prefeitura de Bauru – SP]
ProblemaNa emissão da NFS-e da prefeitura de Bauru – SP, a tag <vLiq> estava sendo gerada com o valor cheio da nota, sem abater as retenções federais, fazendo com que a prefeitura rejeitasse o documento com a mensagem "Rejeitado pela regras municipais: O Valor Líquido da Nota Fiscal não confere com o calculado", bloqueando o faturamento.
CorreçãoAjustado o cálculo da tag <vLiq> para abater as retenções federais do valor líquido da nota, eliminando a rejeição da prefeitura e restabelecendo o faturamento.
[NFS-e] [Prefeitura de Tangará da Serra - MT] Atualização de schema do provedor Centi
[Prefeitura de Tangará da Serra – MT]
Corrigido(a) o schema de envio do provedor Centi para atender à reforma tributária, passando a gerar as tags <CodigoINDOP> e <CodigoClassTrib> exigidas pela prefeitura. A prefeitura ainda rejeita notas com PIS/COFINS retidos alegando ausência do CST, mesmo este constando corretamente no XML conforme o portal de integração do provedor; nesses casos, orienta-se o cliente a contatar a prefeitura, pois a rejeição não decorre do add-on.
TXPDE-7809Inclusão HOTFIX: 07/08/2026Correção
[NFS-e] [Prefeitura de Pedro Leopoldo - MG] Erro tag <tpretpiscofins>, gerando a tag somente com CST diferente de 00, 08 e 09
[Prefeitura de Pedro Leopoldo – MG]
ProblemaA tag <tpRetPisCofins> estava sendo indevidamente ocultada na NFS-e quando o CST do PIS/COFINS próprio era 00, mesmo havendo retenção de PIS/COFINS a informar conforme a NT 007 do provedor.
CorreçãoAjustada a validação de montagem da tag <tpRetPisCofins> para considerar apenas os CSTs 08 e 09, removendo a validação indevida sobre o CST 00 e evitando que a tag deixe de ser gerada nesses casos.
[NFS-e] Homologação da prefeitura de São Sebastião do Passé - BA
[Prefeitura de São Sebastião do Passé – BA]
Homologado(a) o município de São Sebastião do Passé – BA, via provedor Saatri (mesmo provedor já homologado para Mata de São João – BA). Foram realizados testes de comunicação nos ambientes de homologação e produção, com notas autorizadas com sucesso em produção; no ambiente de homologação foi identificada uma falha, já reportada ao suporte do WebService do provedor. O município adequou o schema para ABRASF 2.03, exigindo o preenchimento do código NBS + Item da lista de serviço como código de tributação nacional (6 dígitos).
[NFS-e] [Prefeitura de Rio Grande - RS] Ambiente Homologação não gera as tags <dps_serv_ctribnac>, <dps_cindop> e <dps_ibscbs_valores_trib_cclasstrib> no XML de envio
[Prefeitura de Rio Grande – RS]
Implementada a geração das tags dps_serv_ctribnac, dps_cindop e dps_ibscbs_valores_trib_cclasstrib no XML de envio de NFS-e para o município de Rio Grande – RS, que ainda não estava adequado à reforma tributária e por isso não gerava essas tags no ambiente de Homologação, fazendo com que o documento fosse sempre rejeitado pela prefeitura. A inclusão foi validada e o documento passou a ser autorizado normalmente.
[NFS-e] [Prefeitura de Guariba - SP] Erro tag <cid>, prefeitura com tabela própria de municipios
[Prefeitura de Guariba – SP]
Corrigida a tabela de códigos de município (CID) utilizada na emissão de NFS-e: removido o registro incorreto do município "São Paulo (Capital)" e ajustado o código cadastrado para o município "São Paulo" (4329). Isso elimina a necessidade de editar manualmente a tag <cid> no XML para autorizar notas emitidas para tomadores da capital de São Paulo.
[NFS-e] [Prefeitura de Piraju - SP] Mudança no Link do WebService
[Prefeitura de Piraju – SP]
Implementada a atualização do endereço do WebService utilizado para emissão de NFS-e na Prefeitura de Piraju – SP: o endpoint foi alterado de https://www.issmap.com.br para http://issmap-rps.sp1.br.saveincloud.net.br. O link de impressão do PDF da NFS-e via QR Code também foi atualizado, de https://www.issmap.com.br/ws/rps/QRCode/3/ para http://issmap-rps.sp1.br.saveincloud.net.br/ws/rps/QRCode/3/.
[NFS-e] [Presidente Prudente - SP] Incluir NOVO URLs de produção no WebService para modelo nacional do município
[Prefeitura de Presidente Prudente – SP]
Implementada a URL do layout nacional municipal para emissão de NFS-e na Prefeitura de Presidente Prudente – SP (https://issprudente.sp.gov.br/nfsenacional/nfse) — anteriormente o add-on enviava as notas apenas pela URL do layout ABRASF (http://issprudente.sp.gov.br/ws_nfse/nfseservice.svc?wsdl). Também foi implementada a geração do PDF no layout nacional 2.0.
Observação: não foi possível cancelar a nota autorizada nesse novo layout — o erro ocorre tanto pelo add-on quanto diretamente no portal da prefeitura, indicando uma limitação do lado do município.
TXPDE-7792Inclusão HOTFIX: 05/08/2026Correção
[NFS-e] [Nacional] Ajustar QR Code do PDF da NFSe gerada em produção restrita
[Ambiente Nacional]
ProblemaO PDF da NFSe Nacional estava gerando o QR Code apontando para o ambiente de produção mesmo em notas emitidas em produção restrita, fazendo com que a consulta pela URL do QR Code retornasse que a nota não existe (pois a consulta era feita no ambiente errado).
CorreçãoAjustado o PDF gerado pelo add-on para incluir o QR Code correto, baseado no ambiente de autorização da nota (produção ou produção restrita).
[NFS-e] [Provedor E&L] Incluir URLs de produção dos municípios no novo WebService
[Provedor E&L]
Implementadas as novas URLs de produção do WebService do provedor E&L, que passou a atender à reforma tributária e à sincronização com o Ambiente de Dados Nacional (ADN). O município de Cachoeiro de Itapemirim – ES foi migrado para o emissor nacional, e os demais municípios que estavam no provedor E&L antigo (baseado no XSD ABRASF 2.04) foram migrados para o provedor E&L 2.04. Os testes de validação foram realizados com o município de Guanhães – MG.
⚙Configuração: Para os municípios do provedor E&L 2.04, é necessário gerar o Token de acesso do WebService e informá-lo em Parâmetros Gerais (campo de senha).
[NFS-e] [NotaControl] Melhorar mensagem de trava de envio assíncrono no WebService novo
[Provedor NotaControl]
Implementada melhoria na mensagem exibida quando o envio assíncrono de NFS-e não está disponível no novo WebService do provedor NotaControl (devido à lentidão do serviço). O texto foi tornado mais claro sobre o que o usuário deve fazer para continuar as emissões, reduzindo os chamados de dúvida e questionamentos de clientes sobre o assunto.
[NFS-e] Ajustar validação do add-on quanto a notas autorizadas para a consulta de NFSe pelo Número / Chave e Visualização de PDFs
[Todas as prefeituras]
Implementado(a) o ajuste na validação do add-on para consulta de NFS-e por número/chave e visualização de PDFs: a verificação passa a considerar apenas se a nota possui número e/ou chave, deixando de exigir o preenchimento do campo XmlFile (XML de retorno) na tabela DocHist. Isso permite visualizar o PDF de notas autorizadas pela prefeitura mesmo quando ela não devolve retorno ao add-on.
TXPDE-7758Inclusão HOTFIX: 04/08/2026Correção
[NFS-e] [Nacional] Adicionar número da NFS-e no campo relacionado do DANFSe 2.0, no rodapé
[Ambiente Nacional]
ProblemaO DANFS-e 2.0 gerado pelo add-on não incluía o número da nota no campo relacionado do rodapé, exibindo apenas a chave de acesso, em desacordo com a NT 008.
CorreçãoCorrigido(a) para que o número da NFS-e seja incluído no campo relacionado do rodapé do DANFS-e 2.0, juntamente com a chave de acesso, conforme especificado na NT 008.
[NFS-e] [São José do Rio Preto - SP] Atualização de LINK WEBSERVICE
[Prefeitura de São José do Rio Preto – SP]
Corrigido(a) o link do WebService de NFS-e da prefeitura de São José do Rio Preto – SP, atualizando a URL de comunicação para o novo padrão do provedor GissOnline (GissOnline V2), conforme adequação à Nota Técnica SE/CGNFS-e nº 007, restabelecendo a emissão de documentos que estava impedida desde a descontinuação do WebService anterior em 24/07/2026.
ProblemaAo transmitir a NFS-e para o Emissor Nacional, ocorria a rejeição E0903 quando o campo <tpEnteGov> estava informado (compra governamental) mas o serviço não pertencia à lista da LC 116/2003 (25.05, 15.09, 17.12, 10.05), pois a tag <tpOper> só era gerada quando ambas as condições eram atendidas simultaneamente — quando a documentação do GOV exige apenas uma OU outra condição.
CorreçãoCorrigido(a) para que a tag <tpOper> seja gerada sempre que o campo <tpEnteGov> estiver informado ou o código de tributação nacional (<cTribNac>) corresponder a um dos itens da lista da LC 116/2003 (25.05, 15.09, 17.12, 10.05), sem exigir que ambas as condições ocorram simultaneamente.
[NFS-e] [Todas as prefeituras] Criar parâmetro para destacar os impostos retidos na descrição do documento.
[Todas as prefeituras]
Implementado(a) o parâmetro para destacar as retenções na descrição do serviço do XML de envio da NFS-e, disponível na aba "Parâmetros". Para o município de São Paulo – SP, o preenchimento automático dessa informação foi removido, passando a seguir o que estiver configurado no parâmetro, da mesma forma que as demais prefeituras e o emissor nacional.
[NFS-e] [Provedor NfeCidades] Adoção do DANFSe 2.0 da NFSe Nacional a partir de 01/08/2026
[Provedor NfeCidades]
Implementado(a) a geração do PDF no padrão nacional 2.0 (DANFSe 2.0) para o provedor NfeCidades, a partir de 01/08/2026, conforme adoção do novo layout divulgada pelo provedor.
TXPDE-7726Inclusão HOTFIX: 03/08/2026Correção
[NFS-e] [Prefeitura de Olinda - PE] Quebra de Linha na Descrição do serviço no PDF gerado no AddOn
[Prefeitura de Olinda – PE]
ProblemaAo inserir observações de abertura e fechamento na nota fiscal, o add-on concatenava as informações com quebra de linha, fazendo com que o PDF gerado pelo add-on exibisse a quebra mesmo quando ela não estava presente no XML de envio nem na nota lançada no SAP, causando divergência entre o PDF do add-on e o da prefeitura de Olinda – PE.
CorreçãoCorrigido(a) para que, no provedor Tinus, o add-on não insira mais quebras de linha ao concatenar as observações de abertura e fechamento, alinhando o PDF gerado pelo add-on ao XML de envio e à nota do SAP.
TXPDE-7705Inclusão HOTFIX: 03/08/2026Correção
[NFS-e] [Prefeitura de Arcos - MG] Arquivo FRX para geração do PDF RPS/NFS AUTORIZADA não localizado
[Prefeitura de Arcos – MG]
ProblemaAo gerar o PDF do RPS ou da NFS-e autorizada da prefeitura de Arcos – MG, o sistema retornava erro de arquivo não localizado ("Não foi encontrado arquivo com o nome [ArcosMg.frx]"), impedindo a geração do documento.
CorreçãoCorrigida a geração do PDF de Arcos – MG, acompanhando as mudanças de layout adotadas pelo provedor WebIss — inicialmente adaptado para a DANFS-e 2.0 do Ambiente Nacional e, após o provedor reverter o XML autorizado para o padrão ABRASF, novamente ajustado para seguir esse formato, eliminando o erro de arquivo não localizado e o problema de PDF sem validade jurídica.
[NFS-e] [Prefeitura de Taboão da Serra - SP] Adequação ao Novo Layout PDF inclusão reforma
[Prefeitura de Taboão da Serra – SP]
Implementadas no PDF da NFS-e as informações de IBS/CBS acima da descrição do serviço, atendendo à exigência da Reforma Tributária, e atualizados os campos de retenções na fonte pelo tomador, alinhando o layout do add-on ao PDF gerado pela prefeitura de Taboão da Serra – SP.
[NFS-e] [Nacional] Atualizar layout DANFSe 2.0 para a versão da NT 008 1.02
[Ambiente Nacional]
Implementados os ajustes no layout da DANFSe 2.0 conforme a Nota Técnica 008 (versão 1.02), publicada pelo CGNFSe. As alterações foram aplicadas integralmente conforme especificado na NT, mantendo a conformidade da geração da DANFSe com a especificação nacional mais atualizada.
Problema ao enviar e-mail teste na aba e-mail dos parâmetros da NFCom
ProblemaAo realizar o teste de envio de e-mail na aba de e-mail dos parâmetros da NFCom, ocorria o erro "5.2.252 SendAsDenied", pois o sistema estava utilizando indevidamente o e-mail de teste como remetente na montagem da mensagem, impedindo o envio e travando a tela de parâmetros gerais.
CorreçãoCorrigida a seleção do e-mail de envio na montagem da mensagem, que estava utilizando o e-mail de teste como emissor.
TXPDE-8467Inclusão HOTFIX: 15/10/2026Correção
Add-on esperando o campo StatDlvryP do SAP mas versão do SAP do cliente não possui o campo
ProblemaO add-on de NFCom aguardava o campo StatDlvryP retornado pelo SAP, porém clientes com versões do SAP que não possuem esse campo ficavam impedidos de emitir NFCom, com o faturamento paralisado.
CorreçãoO fluxo de geração do XML da NFCom foi ajustado para não exigir mais essas colunas do banco, permitindo a emissão normal da NFCom mesmo quando o campo não está presente na versão do SAP do cliente.
DCe
1 item
TXPDE-7593Inclusão HOTFIX: 03/08/2026Correção
Erro ao exportar DCE e XML autorizado, o arquivo não é salvo no diretório.
ProblemaAo utilizar a opção "Mais Ações" → "Exportar DACE e XML Autorizado" no DC-e (mesma divergência ocorria no BP-e), a exportação em .zip não gerava nenhum arquivo, mas o sistema exibia a mensagem "Arquivo salvo em: ..." dando ao usuário a falsa impressão de que a exportação havia sido concluída com sucesso. A causa era que a rotina de exportação procurava os arquivos em disco com nomes que o sistema nunca grava (ex.: DCe{chave}, quando o serviço grava procDce{chave}/DACE{chave}); não encontrando os arquivos, o documento era ignorado silenciosamente e o .zip nunca era gerado.
CorreçãoCorrigido(a) para que a exportação utilize o arquivo do diretório do emitente quando ele existir e, quando não existir, recrie o XML e o DACE/DANFE a partir do banco de dados — funcionando corretamente mesmo com a opção "Salvar arquivo no diretório" desativada.
DFe
52 itens
TXPDE-8636Inclusão HOTFIX: 04/11/2026Correção
Falha no reconhecimento de itens de NFS-e com pesquisa avançada habilitada
ProblemaNa importação de NFS-e de entrada, o add-on DFe, na etapa de reconhecimento do item do SAP B1, trazia o item vinculado ao cadastro de código de serviço que tinha o mesmo código de tributação do XML, mesmo quando esse item não estava cadastrado no Número de Catálogo do Parceiro de Negócio.
CorreçãoO DF-e não traz mais o item do Cadastro de Código de Serviço apenas por ter o mesmo código de serviço do XML. Esse item só é usado se estiver cadastrado no Número de Catálogo do fornecedor que emitiu a nota. Se não estiver, o DF-e procura um item do SAP com o mesmo código de serviço, como já fazia. Se não encontrar nenhum item, a nota vem sem item reconhecido, com o código de serviço do XML, e o usuário realiza o De/Para na tela de importação.
TXPDE-8667Inclusão HOTFIX: 03/11/2026Correção
Rascunho removido volta a ser vinculado ao reimportar após processo de autorização
ProblemaAo remover o rascunho de uma NF-e de entrada pelo DF-e e reimportar o documento, o add-on vinculava o rascunho removido ou impedia a importação acusando que o documento já havia sido importado, pois a verificação de duplicidade não considerava rascunhos cancelados no processo de autorização, rascunhos já encerrados, nem notas lançadas a partir de um rascunho e posteriormente canceladas.
CorreçãoA verificação de duplicidade do DF-e passou a considerar corretamente rascunhos cancelados no processo de autorização, rascunhos já encerrados e notas lançadas a partir de um rascunho e depois canceladas, permitindo lançar a NF-e do zero após a remoção do rascunho.
Implementado(a) suporte ao CST 20 no grupo de partilha do ICMS (ICMSPart) do add-on DFe, conforme a Nota Técnica 2022.002 (versão 1.30), permitindo a importação de NF-e com esse valor sem erro de validação. A importação de notas com CST 10 e 90 continua funcionando normalmente.
TXPDE-8531Inclusão HOTFIX: 23/10/2026Correção
Erro ao abrir o Cadastro de Entidade
ProblemaAo tentar acessar o Cadastro de Entidade, o sistema exibia uma mensagem de erro que impedia a abertura da tela, impossibilitando qualquer alteração ou configuração de entidade.
CorreçãoO problema foi corrigido e o Cadastro de Entidade voltou a abrir normalmente.
TXPDE-8536Inclusão HOTFIX: 22/10/2026Correção
QIVE | Captura automática não captura documentos
ProblemaOs serviços automáticos da Qive (Entrada, Eventos e Saída) podiam travar indefinidamente sem registrar o motivo no log, impedindo a identificação da causa da falha na captura automática de documentos fiscais.
CorreçãoAs chamadas aos serviços da Qive passaram a ter um tempo máximo de espera (até 10 minutos). Quando uma consulta ultrapassa esse limite, o log registra qual entidade e documento travaram, e o monitor reinicia o serviço automaticamente, sem necessidade de intervenção manual.
TXPDE-8226Inclusão HOTFIX: 22/10/2026Correção
Erro Oauth2 - The server did not respond with a + response. The response was: "-ERR Basic authentication is disabled."
ProblemaAo configurar a autenticação OAuth 2.0 (Microsoft) para atualização da caixa de e-mail no DFe, ocorria o erro "Server did not accept user credentials... Basic authentication is disabled", pois a rotina de atualização da caixa de e-mail estava implementada apenas para autenticação SMTP tradicional — ao selecionar OAuth 2.0, o add-on executava a mesma rotina do SMTP (autenticação básica via POP3), que a Microsoft já não permite mais.
CorreçãoImplementado o processo de atualização da caixa de e-mail também para autenticação OAuth 2.0, reaproveitando a lógica já existente para SMTP com as adaptações necessárias.
Parâmetro “Considerar Moeda Corrente” na importação com documento base em moeda estrangeira
Implementado(a) o parâmetro “Considerar Moeda Corrente” na Configuração de Recebimentos do DFe. Quando habilitado, o DFe passa a ignorar a moeda estrangeira do documento base (pedido de compra ou de venda) vinculado à nota importada, gerando o documento de marketing no SAP B1 em moeda corrente (R$), com todos os valores também em R$. Na tela de importação, a taxa de câmbio deixa de ser exibida para edição enquanto o parâmetro estiver ativo.
Implementado(a) no add-on DFe a replicação do conteúdo da coluna "Texto livre" dos anexos do documento base para o documento de marketing gerado durante a importação do XML, equiparando o comportamento ao recurso nativo "Copiar para" do SAP B1. Quando o anexo de origem não possuir "Texto livre" preenchido, o campo permanece vazio no documento gerado, sem impacto na importação. O ajuste vale para todos os modelos de documentos fiscais importados pelo add-on (NF-e, CT-e, NFS-e, entre outros).
NFe (55) | Atualizar cClassTrib e cClassTribReg no Cadastro do Item conforme XML
Implementado(a) no processo de "Atualizar Item" a atualização automática do Código de Classificação Tributária do IBS e CBS (cClassTrib) e da Classificação Tributária Regular (cClassTribReg) nos campos de usuário do cadastro do item (U_TX_cclasstr e U_TX_cclasstrreg), conforme os dados informados no XML, para NF-e (55).
TXPDE-8228Inclusão HOTFIX: 20/10/2026Correção
Informações cortando ao exportar notas em lote via DF-e
ProblemaAo gerar o PDF da DANFE dos documentos recebidos (DF-e) em máquinas com a escala de exibição do Windows diferente de 100% (por exemplo, 125% ou 150%), o texto saía cortado ou sobreposto, tanto na exportação em lote (agrupada e separada) quanto na visualização/exportação individual dos documentos importados ou distribuídos.
CorreçãoA geração do PDF da DANFE do DF-e passou a fixar a resolução (DPI 96) durante a geração, eliminando a dependência da escala de tela da máquina. O ajuste cobre a exportação em lote (agrupada e separada) e a visualização/exportação individual de NF-e, CT-e/CT-e OS e NFS-e municipal, ficando limitado ao módulo DF-e (documentos recebidos) — NFCom, MDF-e, DC-e e BP-e não fazem parte desta entrega (o NFCom será tratado como item separado), e os fluxos de emissão (NF-e/NFC-e) e a NFS-e nacional continuam funcionando como antes.
Processo de importação do CTe Simplificado - Atualização Schema
Corrigida a importação do CT-e Simplificado no DFe: uma atualização do schema trocou a tag raiz do XML de <cteSimpProc> para <cteProcSimp>, causando rejeição na importação ("Arquivo não é um xml de recebimento válido..."). O importador foi ajustado para aceitar ambos os formatos, já que não há garantia de que o formato anterior tenha sido descontinuado por todos os emissores.
Implementar coluna "Documento Base" na tela de Administração
Implementado(a) a coluna "Documento Base" na tela de Administração do DFe, exibindo o número do documento base vinculado ao documento importado. Quando houver mais de um documento base vinculado, é exibido um indicador para listar todos os documentos relacionados, seguindo o mesmo comportamento já existente na funcionalidade de Referência de Notas.
Inclusão de novas colunas na tela de Administração
Implementado(a) a exibição de novas colunas na tela de Administração de DF-e: Nome do Tomador/Destinatário e Endereço do Tomador/Destinatário (obtidos das tags xNome e enderDest/toma/enderToma), Valor da Carga para Averbação (tag vCargaAverb) e a coluna Número na modal de Documento Referenciado, calculada a partir dos dígitos do campo nNF na chave de acesso, contemplando tanto o CT-e Simplificado quanto o CT-e modelo 4.00. Também foi corrigido o carregamento de notas referenciadas do CT-e Simplificado e uma falha de importação em CT-e 4.00 sem o grupo dest.
TXPDE-8511Inclusão HOTFIX: 14/10/2026Correção
Implementar valor 6 na tag 'TpImp'
Problemaao importar um XML pelo DFe contendo o valor 6 na tag TpImp (novo valor previsto na NT 2026.002), era apresentado o erro de schema "'6' is not a valid value for TNFeInfNFeIdeTpImp", impedindo a importação do documento.
Correçãoadicionado o valor 6 como válido para a tag TpImp, permitindo a correta importação do XML.
Permitir atualizar manualmente a entidade do documento através do documento base
Implementado(a) o funcionamento do parâmetro que substitui a entidade do documento pelo documento base também quando o documento base é atribuído manualmente, não apenas quando vinculado automaticamente pelo campo xPed. Além disso, a busca da filial de destino passou a conferir CPF/CNPJ e inscrição estadual, evitando que o documento seja importado em uma filial de outro CNPJ.
TXPDE-8468Inclusão HOTFIX: 13/10/2026Correção
Espaçamento indevido na grade de itens do PDF da NF-e
ProblemaAo visualizar uma NF-e pelo botão "Mais ações > Visualizar PDF / Retrato", o add-on DFe gerava um espaçamento indevido no cabeçalho da grade de itens do PDF, diferente do layout gerado pelo add-on NFe.
CorreçãoAjustado o cabeçalho dos itens no add-on DFe para que fique visível corretamente na impressão da Danfe, alinhando o layout da grade de itens ao gerado pelo add-on NFe.
Implementar Permissões de Visualização Restrita por Fornecedor
Implementada, no add-on DFe, uma nova aba de configuração "Permissões de Visualização Restrita por Fornecedor", que permite restringir, por fornecedor, quais usuários do SAP Business One podem visualizar as NFS-e recebidas desse fornecedor. Fornecedores não configurados na tela mantêm o comportamento padrão, ficando visíveis a todos os usuários. A tela permite vincular fornecedores e usuários em lote e exportar/importar as configurações via planilha Excel. O acesso é controlado por uma nova autorização específica em Autorizações Gerais do SAP Business One, com o mesmo nome da tela.
TXPDE-8229Inclusão HOTFIX: 09/10/2026Correção
Ajustar Data e Hora da DANFSe (PDF NFSe Ambiente Nacional)
ProblemaCom a mudança para o layout DANFSe 2.0 da NFSe Nacional, os campos de data e hora de emissão (NFSe e DPS) e de competência passaram a ser exibidos incorretamente no PDF, pois a leitura das tags de data considerava apenas um formato fixo, não interpretando corretamente valores em outros formatos válidos.
CorreçãoAjustado o tratamento das tags de data para considerar corretamente o fuso horário informado no XML: datas com fuso -03:00 mantêm o horário original (já em horário de Brasília); com fuso Z ou +00:00, o horário é convertido para Brasília (-3h); com fuso -04:00 (ex.: Manaus), é convertido para Brasília (+1h); com fuso -00:00/-0000 (fuso desconhecido conforme RFC 3339), o horário informado é mantido sem conversão. Datas sem horário (ex.: competência) ou sem informação de fuso são mantidas como informadas, e tags vazias, nulas ou com conteúdo inválido passam a utilizar o valor padrão da aplicação.
TXPDE-8470Inclusão HOTFIX: 08/10/2026Correção
Valor total da NF-e não é convertido quando o documento base está em moeda estrangeira
ProblemaAo vincular um XML de NF-e a um pedido base em moeda estrangeira, o DF-e lançava o valor total da nota em reais como se já estivesse na moeda do pedido, sem realizar a conversão, multiplicando o valor do documento pela cotação do dia.
CorreçãoO valor em reais da nota agora é convertido para a moeda do pedido base antes da criação do documento, utilizando a cotação do dia. Os valores da nota, do frete e das demais despesas passam a sair corretamente na moeda do documento base.
TXPDE-8412Inclusão HOTFIX: 07/10/2026Correção
DFe - Inconsistência na procedure UpdateStatusDocReceived
Problemaao atualizar o documento após a importação, a procedure UpdateStatusDocReceived gravava no campo DocNum o mesmo valor do DocEntry, fazendo com que o DF-e não localizasse o documento no SAP e gerando erro ao abrir o documento pela tela do DF-e.
Correçãoa procedure UpdateStatusDocReceived foi corrigida para atualizar corretamente o DocNum ao efetivar o esboço no SAP, permitindo que o DF-e identifique o documento corretamente.
TXPDE-8376Inclusão HOTFIX: 06/10/2026Correção
Problema na interpretação dos itens por unidade de medida
Problemaao importar itens que possuíam o mesmo nome de Unidade de Medida, mesmo pertencendo a Grupos de Unidade de Medida diferentes, o DFe replicava indevidamente a conversão da primeira Unidade de Medida encontrada para os demais itens, desconsiderando o Grupo de Unidade de Medida cadastrado individualmente para cada item.
Correçãofoi ajustada a query de obtenção da quantidade utilizada pelo processo de Unidades por Fornecedor, que passa a considerar corretamente a conversão de cada item conforme o seu respectivo Grupo de Unidade de Medida.
TXPDE-8366Inclusão HOTFIX: 06/10/2026Correção
Importação QIVE duplicando item na Nota de serviço
Problemauma NFS-e de entrada com um único serviço era importada no DFe com dois itens, pois o add-on buscava o item simultaneamente pelo catálogo do fornecedor e pelo cadastro de Código de Serviço, somando os dois resultados.
Correçãoo DFe passa a usar apenas a primeira busca que encontrar o item — na entrada, o catálogo do fornecedor é consultado primeiro, e o cadastro de Código de Serviço só é utilizado caso o catálogo não retorne resultado. Com isso, cada serviço da nota volta a gerar uma única linha, com o valor correto, tanto na importação quanto na tela de Análise dos Itens.
TXPDE-8232Inclusão HOTFIX: 06/10/2026Correção
Problema na data de vencimento das NFSe ADN
ProblemaNa importação individual ou em lote de uma NFSe ADN, o add-on DFe não calculava corretamente a data de vencimento com base nas condições de pagamento do parceiro de negócio, não respeitando as configurações cadastradas no SAP B1 como já ocorria com as notas modelo NFe.
CorreçãoCorrigido o cálculo da data de vencimento no DFe para importação de NFSe nacional e municipal, passando a respeitar corretamente as condições de pagamento cadastradas para o parceiro de negócio.
TXPDE-8426Inclusão HOTFIX: 05/10/2026Correção
Erro na condição de pagamento ao importar documento com moeda estrangeira
ProblemaAo importar um documento em moeda estrangeira com condição de pagamento contendo duas ou mais parcelas, o DFe apresentava erro ao tentar criar o esboço, pois as parcelas geradas não fechavam 100% do total exigido pelo SAP.
CorreçãoFoi ajustada a forma como o add-on cria as parcelas da nota quando o documento está em moeda estrangeira, para que elas sempre fechem 100% do total. Isso vale tanto para notas com uma quanto com várias parcelas, vindas do pedido de compra ou do próprio XML; notas em reais e os demais cenários continuam funcionando como antes.
TXPDE-8399Inclusão HOTFIX: 05/10/2026Correção
Problema na alteração individual dos itens durante a importação
ProblemaAo importar um documento no DFe com mais de um item, estando habilitado o parâmetro "Permitir alterar item ao importar documento", ao selecionar outro item para uma das linhas durante a importação, o add-on atribuía o mesmo item selecionado para todas as demais linhas, em vez de alterar apenas o item correspondente.
CorreçãoO processo de alteração individual de itens foi ajustado para considerar o modelo do documento no qual o item será importado, eliminando a replicação indevida do item alterado para as demais linhas.
TXPDE-8251Inclusão HOTFIX: 05/10/2026Correção
Problema na captura de CTe via QIVE.
ProblemaNa captura de CT-e via QIVE, o add-on validava corretamente a empresa pelo tomador do frete em uma primeira etapa, porém uma segunda etapa sempre considerava o destinatário do documento, podendo vincular o CT-e à entidade errada quando o tomador (indicado pela tag toma) não coincidia com o destinatário.
CorreçãoEssa segunda etapa de validação passou a utilizar também o tomador do frete, da mesma forma que já ocorria na captura direta pela Sefaz. O comportamento da NF-e não foi alterado.
TXPDE-8374Inclusão HOTFIX: 28/09/2026Correção
4UNITY | Problema na captura de NFSe
ProblemaAo capturar as NFS-e do provedor externo 4UNITY, o add-on DFe não trazia todas as notas disponíveis no painel do provedor, pois a consulta considerava apenas as 50 primeiras notas retornadas pela paginação.
CorreçãoO sistema passou a registrar o ponto da última consulta realizada, retomando a partir dele em vez de reiniciar do início a cada busca; caso alguma nota não seja gravada, a próxima consulta retorna ao ponto onde falhou. Quando a lista do provedor não vem paginada corretamente, todas as notas são baixadas de uma só vez, e notas já existentes no sistema deixam de ser importadas novamente.
TXPDE-8355Inclusão HOTFIX: 28/09/2026Correção
DFe - Erro na importação de NF-e com documento base vinculado
ProblemaAo importar uma NF-e como esboço com documento base vinculado e tentar adicionar o esboço no SAP, ocorria o erro "Nenhum registro concordante encontrado" (PDN2) (ODBC -2028) [Mensagem 131-183].
CorreçãoO erro era causado pelo preenchimento incorreto de despesas adicionais no documento de rascunho quando o documento base vinculado não continha despesas adicionais preenchidas. O add-on passou a preencher as despesas adicionais no rascunho apenas quando o documento base também as contiver.
TXPDE-8259Inclusão HOTFIX: 28/09/2026Correção
Problema na validação do tomador das notas capturadas via QIVE
Problemaao configurar no add-on várias entidades com CNPJs diferentes utilizando os mesmos dados de captura do QIVE, o DFe não validava se o CNPJ da entidade correspondia ao do tomador do documento, fazendo com que todas as notas fossem capturadas por todas as filiais configuradas, mesmo quando a filial não era a tomadora do XML, gerando duplicidade de notas.
Correçãoimplementada a validação para que o processo de captura via QIVE verifique se o CNPJ cadastrado na entidade corresponde ao do tomador do documento antes de atribuí-lo à entidade correta, da mesma forma que já ocorre na captura via SEFAZ.
TXPDE-8289Inclusão HOTFIX: 25/09/2026Correção
Addon considerando a condição de pagamento do pedido indevidamente.
Problemao addon DFe passou a considerar a condição de pagamento do pedido indevidamente, mesmo com o parâmetro correspondente desmarcado — uma regressão introduzida pela TXPDE-7155.
Correçãocom o parâmetro desmarcado, o DFe volta a utilizar a condição de pagamento do parceiro e as parcelas do XML, tanto na entrada quanto na saída, restabelecendo também a regra da TXPDE-3176; o comportamento do contrato guarda-chuva permanece inalterado.
TXPDE-7746Inclusão HOTFIX: 21/09/2026Correção
Consulta de CTE não valida "Data do Ultimo Documento Cte"
ProblemaA regra de espera de 1 hora entre consultas de NF-e/CT-e considerava apenas o horário da última consulta sem documentos, ignorando a data — fazendo o serviço pausar as buscas por até 1 hora mesmo quando a última consulta havia sido em um dia anterior.
CorreçãoAjustada a regra de espera para considerar corretamente data e hora da última consulta. Também foi tratado o cenário em que ainda não existe data do último documento, evitando bloqueio da consulta nesse caso. Vale tanto para download de NF-e quanto de CT-e.
TXPDE-8225Inclusão HOTFIX: 11/09/2026Correção
Anexos não são importados em processo via serviço
ProblemaNa importação automática via serviço, os anexos do documento de marketing não eram importados no fluxo de NFS-e (a importação manual e os demais modelos de documento não eram afetados).
CorreçãoO serviço passou a buscar e enviar os anexos já salvos do documento, da mesma forma que os demais fluxos já faziam, anexando apenas o que o cliente tiver configurado para anexar. Validado que a mudança não afeta NF-e, CT-e, NFCom nem a importação manual.
TXPDE-8182Inclusão HOTFIX: 08/09/2026Correção
DFe - Erro ao criar campos — AddValidaValuesIfNotExists
ProblemaAo clicar em "Criar Campos", se a atualização de valores válidos de algum campo específico falhasse, o processo era interrompido por completo, apresentando a mensagem genérica "O valor padrão não é válido para este campo", sem indicar qual campo estava causando o erro.
CorreçãoAgora, se um campo específico falhar durante a criação, o processo segue normalmente para os demais campos, em vez de ser interrompido por completo. Também foi aprimorada a mensagem de erro, que passa a indicar exatamente qual campo e tabela causaram o problema.
TXPDE-8181Inclusão HOTFIX: 08/09/2026Correção
DFe - Análise de alto consumo do Add-on
ProblemaClientes relataram alto consumo de CPU, memória e disco no ambiente, causado por rotinas de inicialização repetidas a cada conexão com o banco, consultas redundantes de leitura de configuração e cálculo do usuário de inclusão manual documento por documento na tela de documentos recebidos.
CorreçãoA rotina de inicialização passou a rodar uma única vez por banco, quando o serviço sobe, em vez de se repetir a cada conexão. A leitura da configuração de um único registro foi reduzida de três consultas ao banco para uma. A atualização de uma procedure do SAP saiu dos serviços e passou a ser feita pelo add-on ao salvar as configurações, como os demais módulos já faziam. Na tela de documentos recebidos, o usuário da inclusão manual passou a ser buscado de uma só vez, em vez de documento por documento.
TXPDE-8163Inclusão HOTFIX: 08/09/2026Correção
DFe - Erro ao importar documento com pedido base em moeda estrangeira.
ProblemaAo vincular um pedido base em moeda estrangeira (dólar) a uma nota fiscal e clicar em "Inserir", o sistema apresentava o erro "Taxa na linha deve coincidir com a taxa do documento", pois o add-on utilizava a cotação da data do documento base, enquanto o SAP aplicava a cotação da data do documento (nota).
CorreçãoO add-on passou a utilizar sempre a cotação da data do documento (nota), da mesma forma que o recurso "Copiar Para" do SAP realiza, fazendo com que todas as linhas do documento fiquem com a mesma cotação do cabeçalho, cobrindo também os casos em que não existe cotação do dia.
TXPDE-8002Inclusão HOTFIX: 08/09/2026Correção
DFe - Retenção dos impostos sendo preenchida incorretamente.
ProblemaNo processo de importação de NF-e com preenchimento automático de retenção de impostos habilitado, o add-on DF-e preenchia a linha de imposto retido com base no código informado no XML da nota, escolhendo um código qualquer quando não encontrava um cadastrado compatível, o que impedia o SAP de aplicar sua própria determinação de impostos.
CorreçãoO add-on passou apenas a marcar a nota como sujeita a imposto retido quando o XML indica retenção, deixando que a determinação de impostos do SAP preencha os códigos e valores, produzindo o mesmo resultado do lançamento manual do documento no SAP, sem regressão no comportamento já corrigido anteriormente (TXPDE-6166).
TXPDE-8027Inclusão HOTFIX: 01/09/2026Correção
2 | Problema ao verificar duplicidade para documentos que passaram pelo processo de autorização do SAP B1.
Problemafoi identificada uma falha no processo de vinculação de documentos relacionados a pedidos com fluxo de aprovação, que impactava indevidamente também os documentos do fluxo normal, sem aprovação. O sistema tratava como rascunho documentos que já haviam sido efetivados, e em alguns casos abria o documento em rascunho no lugar do documento definitivo já emitido. Havia também um erro na seta laranja, que abria o documento pelo docEntry correto, porém exibindo o tipo de documento incorreto quando o processo envolvia aprovação ou rascunho.
Correçãocorrigido o processo de vinculação de documentos para não tratar mais como rascunho os documentos já efetivados, corrigida a abertura do documento definitivo em vez do rascunho, e ajustada a seta laranja para exibir o tipo de documento correto.
TXPDE-7995Inclusão HOTFIX: 28/08/2026Correção
DFe - Anexo sendo levado indevidamente ao documento destino.
ProblemaAo importar um documento vinculando um documento base pelo DFe, todos os anexos do documento base eram levados indevidamente ao documento de destino, mesmo os que não estavam marcados para isso.
CorreçãoA importação pelo DFe com documento base vinculado passa a respeitar a marcação "Copiar para documento de destino" já existente no anexo do SAP, levando automaticamente apenas os anexos assim marcados. Na aba Anexos da tela de importação, quando há documento base vinculado, os anexos do documento base passam a ser exibidos junto aos do DFe com uma coluna de seleção por linha, permitindo que o usuário marque ou desmarque cada anexo antes da gravação; apenas os selecionados são levados ao documento de destino.
TXPDE-7601Inclusão HOTFIX: 27/08/2026Correção
Problema na interpretação dos manifestos da NFSe Nacional (ADN
Problemao download de eventos da NFS-e Nacional falhava quando a descrição do evento (por exemplo, de cancelamento ou manifesto) vinha em formato diferente do esperado, pois o sistema tentava corrigir esses textos individualmente e isso não cobria todos os casos.
Correçãoa descrição do evento passou a ser ignorada durante a leitura, sendo o processamento realizado apenas com as demais informações do manifesto, evitando que variações de texto em eventos de cancelamento, manifesto e outros quebrem o download.
TXPDE-7978Inclusão HOTFIX: 25/08/2026Correção
DFe - Observações não são enviadas ao documento importado.
ProblemaAo importar documentos ao SAP (em lote ou individualmente), as observações digitadas pelo usuário na tela de importação não eram gravadas no documento quando o parâmetro "Enviar conteúdo das tags InfAdFisco e InfCpl para as observações do documento de marketing" estava desmarcado, pois esse parâmetro bloqueava indevidamente a gravação de todo o campo Observações, e não apenas do texto automático vindo do XML.
CorreçãoCorrigido para que os dois conteúdos sejam tratados de forma independente — o parâmetro passa a controlar somente o texto automático vindo do XML, enquanto a observação digitada pelo usuário passa a ser sempre respeitada e enviada ao documento.
TXPDE-8227Inclusão HOTFIX: 24/08/2026Correção
General error;326 CURRVAL of given sequence is not yet defined in this session
ProblemaEm 22/08, um erro nas tabelas temporárias do DFeWebClient fez com que todas as notas ficassem com status de erro interno no add-on:
General error;326 CURRVAL of given sequence is not yet defined in this session: cannot find currval location by session_id:341290, seq id:2720280, seq version:1
Erro ao criar tabelas temporárias. Data DocumentInstallments not found
Um hotfix aplicado no mesmo dia removeu a verificação de restrições do serviço de importação automática (verificação originalmente criada para o processo de importação manual), mas essa mudança impactou outro processo em uso desde o go-live do webClientDFe: um cliente que importa notas de devolução automaticamente, mas que por processo interno só pode importar notas de entrada manualmente, passou a ter notas de entrada importadas automaticamente de forma indevida, exigindo o cancelamento das entradas geradas incorretamente.
CorreçãoComo o DFe não possuía uma configuração para diferenciar esse cenário, o serviço passou a verificar, por tipo de documento, se existe restrição cadastrada — havendo restrição, o documento deixa de ser importado automaticamente para o SAP. Também foi corrigido o processo para atualizar a coluna IncludeDocument para 0 quando a nota tem restrição: antes, o erro de restrição não era exibido em tela e a coluna permanecia em 1, fazendo o serviço tentar importar a mesma nota repetidamente.
TXPDE-7770Inclusão HOTFIX: 24/08/2026Correção
Validação incorreta da quantidade do XML ao utilizar Unidade por Fornecedor
ProblemaQuando a configuração de Unidade por Fornecedor estava habilitada no add-on DFe e era realizada a atribuição de um documento base, o sistema exibia incorretamente a mensagem "Quantidade do XML é menor que a quantidade do documento base", pois a validação não considerava a conversão da unidade configurada para o fornecedor ao comparar as quantidades.
CorreçãoA validação do add-on DFe foi ajustada para converter as quantidades do XML e do documento base para a mesma unidade antes de compará-las, corrigindo a mensagem exibida na tela de atribuição de documento base. Quando não há diferença de unidade entre o XML e o documento, o comportamento permanece exatamente como era.
TXPDE-7762Inclusão HOTFIX: 24/08/2026Melhoria
Melhoria na interpretação da tag xNome para identificação do item de pedágio
Implementado(a) melhoria na interpretação da tag xNome para identificação do item de pedágio no CT-e do add-on DF-e. Agora a identificação ocorre sempre que o texto contiver a palavra "pedágio", independentemente de acentuação, caixa (maiúsculas/minúsculas) ou de haver outros caracteres antes ou depois do termo (anteriormente era necessário que o conteúdo fosse exatamente "PEDAGIO").
Erro ao importar manualmente NFSe do Ambiente Nacional
ProblemaAo realizar a importação manual de uma NFSe do Ambiente Nacional, o processo era interrompido por uma exceção ("Object reference not set to an instance of an object"), impedindo a inclusão do documento no sistema.
CorreçãoCorrigida a rotina de importação manual de NFSe do Ambiente Nacional, que agora é concluída com sucesso, sem gerar exceções.
TXPDE-7944Inclusão HOTFIX: 19/08/2026Correção
Problema na atribuição de documento base com moeda estrangeira
ProblemaAo importar um XML e atribuir, durante o processo, um documento base que continha valores em moeda estrangeira, o DFe apresentava mensagem de erro, impossibilitando a conclusão da importação do documento. O problema ocorria somente quando o documento era importado diretamente, sem a utilização da opção de importação como rascunho.
CorreçãoAjustado o DFe para permitir a importação do documento mesmo quando for atribuído um documento base que utilize moeda estrangeira, garantindo que o processo seja concluído corretamente, independentemente da modalidade de importação.
TXPDE-7789Inclusão HOTFIX: 18/08/2026Correção
QIVE | Não está capturando o evento de cancelamento da NFe
ProblemaNa consulta de documentos via provedor externo QIVE, os eventos de cancelamento de NF-e não eram capturados. Mesmo com a nota devidamente cancelada na Sefaz, o DFe não importava essa informação, e o evento de cancelamento não era exibido na tela de Administração do DFe, deixando o status do documento sem ser atualizado para Cancelado.
CorreçãoO serviço de eventos do provedor externo buscava uma configuração errada e repetia a consulta de notas de saída em vez de consultar a fila de eventos da Qive; o serviço foi corrigido para consultar de fato os eventos, e empresas com configuração antiga passam a ter esse cadastro criado automaticamente, sem necessidade de refazer nada na tela. A consulta enviada à Qive também foi ajustada, pois usava filtros não aceitos pela fila de eventos, o que podia impedir o retorno. A rotina ficou mais resistente a falhas, de forma que um evento com problema ou o fim da fila não descartam mais o lote inteiro, e o cancelamento passa a atualizar o status do documento para Cancelado.
TXPDE-7799Inclusão HOTFIX: 12/08/2026Correção
Problema na barra de rolagem da tela "Tipo de Documento por CFOP"
ProblemaA tela "Tipo de Documento por CFOP" perdeu a barra de rolagem nas versões mais recentes, dificultando a visualização completa das linhas quando o usuário possui uma grande quantidade de registros cadastrados.
CorreçãoA tabela foi redimensionada para caber corretamente dentro da aba, usando a mesma proporção já adotada em outra tela equivalente do sistema. Com isso, a barra de rolagem voltou a aparecer e a navegação entre todas as linhas foi restabelecida, mantendo o ajuste correto quando a janela é redimensionada.
Considerar todos os campos de usuário do documento base
Implementado o parâmetro "Considerar todos os campos de usuário do SAP Business One" nas configurações de recebimento do DFe: quando habilitado, o add-on passa a replicar para a nota gerada todos os campos de usuário preenchidos no documento base (cabeçalho e linhas), reproduzindo o mesmo comportamento nativo do "Copiar para" do SAP Business One. Quando desabilitado, o comportamento atual é mantido, sem impacto para os demais clientes.
⚙Configuração: Habilitar o parâmetro "Considerar todos os campos de usuário do SAP Business One" nas Configurações de Recebimento do DFe.
"Utilização" e "Uso Principal" do Parceiro de Negócios não são considerados na importação de notas
ProblemaAo importar uma nota fiscal pelo add-on DFe, não era considerada a Utilização (Uso Principal) configurada no cadastro do Parceiro de Negócios quando nenhuma utilização era informada durante a importação nem havia documento base vinculado, divergindo do comportamento nativo do SAP Business One.
CorreçãoO add-on passou a buscar o Uso Principal cadastrado no Parceiro de Negócios nesses casos, preenchendo automaticamente os campos "Utilização" e "Uso Principal", reproduzindo o comportamento do SAP. A alteração vale tanto para notas de produto quanto de serviço, nos modos de importação manual (pela tela) e automática.
TXPDE-7655Inclusão HOTFIX: 06/08/2026Correção
Inconsistência no XML da NFSe capturada via ADN
ProblemaAo capturar uma NFSe Nacional via ADN e acessar "Mais Ações > Visualizar XML", o XML gerado pelo add-on DFe apresentava inconsistências: o arquivo não podia ser aberto em navegadores (era considerado inválido) e, ao ser aberto no Notepad++, exibia diversos caracteres "NULL" ao final da estrutura, indicando conteúdo inválido/bytes excedentes.
CorreçãoAjustado o tratamento do conteúdo da NFS-e capturada via ADN antes de ser salvo — aplicado à nota, aos eventos e ao XML salvo em pasta, além da geração do arquivo para visualização ou compactação em lote. Com isso, as notas já capturadas no ambiente passam a abrir corretamente, sem necessidade de nova captura. O tratamento ficou restrito à NFS-e; NF-e, CT-e e os demais documentos continuam inalterados, e a assinatura digital não é afetada.
TXPDE-7641Inclusão HOTFIX: 05/08/2026Correção
Problema na verificação de múltiplos itens
ProblemaNa tela de Análise dos Itens do DF-e, ao selecionar vários itens e clicar em "Verificar" > "Atualizar Itens", as opções que permitiam atualizar múltiplos itens de uma vez (em especial "Todos os dados") deixaram de aparecer, fazendo com que apenas uma das linhas selecionadas fosse atualizada por execução.
CorreçãoCorrigida uma regressão introduzida em junho/2026 pela tarefa TXPDE-6901, restaurando a exibição do menu de opções e fazendo com que a atualização volte a considerar todas as linhas selecionadas, sem perder os ajustes feitos naquela tarefa.
TXPDE-7757Inclusão HOTFIX: 04/08/2026Correção
Inconsistência no preenchimento do campo CPF do emitente no DANFE
ProblemaNo DANFE (retrato e paisagem), o campo do emitente exibia apenas o CNPJ; quando o emitente da NF-e era pessoa física (informado por CPF em vez de CNPJ), o campo ficava em branco.
CorreçãoO layout passou a considerar também o CPF do emitente (mesmo padrão já usado para o destinatário), aplicado nos 6 layouts existentes (9 cópias no total: retrato rastro, retrato Arma e os 4 modelos paisagem). Nos dois modelos retrato, o rótulo do campo foi ajustado para "CNPJ / CPF".