elton.barbosa

Outra possibilidade que pode estar acontecendo é a mudança do provedor de Ginfes para GissOnline. Se tentou tudo acima e continua com problemas, verifique se houve essa mudança de provedores. Veja esse tópico de notícias para mais detalhes:

Atualização 2026/02/26 16:00: Recebemos notícias que foi normalizado a situação. Post Original abaixo: ----------- Olá pessoal, Queremos informar que estamos recebendo diversos relatos que o Emissor Nacional da NFSe está tendo problemas. A mensagem é a seguinte: Se receber a mensagem há apenas duas coisas a fazer: 1) Reportar o problema ao Emissor Nacional. Parece que o problema já foi reportado, mas quanto mais pessoas o fizerem talvez fique claro que é urgente. Não esqueça de informar em qual ambiente você está tentando emitir (produção ou produção restrita). O seguinte link pode ser usado para isso: https://www.gov.br/nfse/pt-br/canais_atendimento/contact-info 2) Ter paciência, aguardar e continuar testando. A qualquer momento pode ser que seja resolvido. Mas não temos como fazer nada do nosso lado. Informe seus clientes para que eles fiquem mais tranquilos ao saber que o problema não é com vocês. Bom trabalho pessoal.

Para futura referência, vejam por favor: ,

É preciso seguir os passos citados:

Na verdade, pode não ser uma boa ideia rodar instalação de só alguns desses pacotes. Talvez precise rodar a instalação de todos novamente e por isso sugerimos rodar o ACBrInstall. A explicação do motivo é a opção "Deixar somente a LibXX", como o Daniel explicou:

Essa função foi introduzida no Delphi XE2, se não me engano. Ou seja, não podemos utilizar já que, no nosso caso, precisamos manter a compatibilidade com versões anteriores do delphi (XE, 2010, 2009, 2007 e 7). Sim... nós já detectamos isso. Inclusive, foi o comentário que eu fiz no tópico relacionado do Diogo Loff. Estamos fazendo testes para validar a remoção do DecodeToString() antes de enviar ao SVN. Nosso amigo @Diego Folieneestá ajudando com respeito a isso. Acredito que ainda hoje vamos enviar uma alteração nesse respeito. Vai ser preciso depois avaliar mais profundamente esse caso, mas aí vamos criar testes. Essa parte eu não sei se entendi direito. Pode explicar melhor?

Vamos fazer isso. Obrigado pela compreensão. Eu concordo. O complicado no nosso caso é que nós não temos escolha, já que precisamos manipular o conteúdo desses arquivos e precisamos fazer isso em IDEs e versões diferentes (Delphi 7 a 13/FPC) e também plataformas diferentes (linux/Windows). Moderação: Fechando, continuar sobre o problema de UTF-8 no tópico:

Muito obrigado pela rápida resposta. Poderia testar com essas outras duas, por favor? PadraoNacional.Provider.pasACBrXmlDocument.pas

Uma possível solução que acho que tem o mesmo efeito é alterar o segundo parâmetro da função DecodeToString para False: //linha594 if NFSeXml <> '' then NFSeXml := DecodeToString(DeCompress(DecodeBase64(NFSeXml)), False); E outra que o @Gabriel Bonzanini compartilhou no outro tópico relacionado foi alterar adicionando ACBrAnsiToUTF8: if NFSeXml <> '' then NFSeXml := ACBrAnsiToUTF8(DecodeToString(DeCompress(DecodeBase64(NFSeXml)), True)); Mas tenho receio qualquer uma dessas possa vir a causar quebras de códigos em outras situações, como lazarus ou Delphi 7. Precisamos validar todas as opções e isso é o que mais tem dado trabalho. Mas obrigado pela sugestão.

@Patrick Knopf, @xandebugmann, @Gênesis Interno, @Rogerio Morato Scarazatti, @Diogo Loff e outros interessados... As units só serão disponibilizadas no SVN depois que os testes e validações forem feitas. No momento precisamos que testem com as units providas pelo Daniel aqui (conforme abaixo) e reportem se funciona. Lembrando que após substituir essas units é necessário fazer uma nova instalação. Se puderem ajudar nos testes agradecemos: Para quem está tentando propor possíveis soluções, elas precisam ser validadas em versões diferentes do Delphi (7 - 13) e Lazarus, além de funcionar no Windows e Linux.

Apenas para registro, as alterações proposta nesse tópico já estão no SVN. Em caso de continuar com problemas, por favor, verifique a situação e crie um novo tópico.

Veja também:

Movi o tópico para a área aberta. Queremos que ele alcance maior parte da comunidade. Em vista de nosso backlog, gostaríamos de que outras pessoas pudessem verificar sua necessidade e se possível contribuir com a implementação.

Dei uma olhada geral sobre o Declaração dos Regimes Específicos (DeRE). Link para documentação e site oficial: http://sped.rfb.gov.br/pagina/show/2919 O formato é XML que será validado por schemas (XSD) e assinado para depois ser transmitido por WebService para um Ambiente Nacional da DeRE. O envio pode acontecer em lotes e o processamento é assíncrono. Notei que as informações e os nomes utilizados se assemelham ao Reinf e e-Social. Por exemplo chamam os arquivos XML de eventos (veja 2.1) e usam uma nomenclatura D-XXXX, por ex. D-1001, D-1011 e D-9001. Assim, talvez esses sejam os componentes mais similares na implementação. Pontos que eu achei de interesse no manual para quem fizer a implementação: Sobre a questão: A legislação que estabelece diz: A DeRE está especificada no Art. 1º § 2º. Então teoricamente, é o mesmo prazo. Relacionado:

Para o Padrão Nacional não existe, como eu disse anteriormente. E até onde eu sei, também não existe uma Norma Técnica definindo isso para outros "provedores". Considerando que tudo é uma questão de legislação municipal e no Brasil temos mais de 5 mil, talvez algum provedor de algum município tenha uma sugestão de leiaute. Mas eu desconheço.

Desculpe... não entendi sua pergunta. Pode elaborar novamente?

Atualmente não existe um padrão nacional definido para a impressão do DANFSe. Por isso cada município pode adotar o formato que considerar adequado. O modelo impresso pelo ACBr já contempla todos os dados previstos no XML, garantindo a integridade das informações e sem trazer prejuízo na utilização. Até o momento, não temos conhecimento de nenhuma legislação municipal que exija um layout específico para o DANFSe. Por isso, embora estejamos avaliando possíveis ajustes, não temos previsão de alterar nossos modelos de impressão para ficar idêntico ou mais semelhante ao modelo GOV no momento. Em tempo, a ACBrLib e o ACBrMonitor não funcionam com o modelo de impressão do Fast Report.

Olá @Light System Software, Por favor, sempre crie um tópico novo para uma dúvida nova conforme as regras. Veja neste link aqui, em especial a "2.2 - Permaneça no assunto". Dessa vez, eu dividi o tópico para você. Sobre sua dúvida: Veja os campos (nessa ordem): NFSe.IBSCBS.finNFSe NFSe.IBSCBS.indFinal NFSe.IBSCBS.IndOpeOne

Eu não sei se isso é possível. Pelo exemplo da documentação, o XML é diferente e por isso teria que modificar a geração dele. Conforme abaixo: <tpNFTS><TipoDocumento>VALOR</TipoDocumento><ChaveDocumento><InscricaoMunicipal>VALOR</In scricaoMunicipal><SerieNFTS>VALOR</SerieNFTS><NumeroDocumento>VALOR</NumeroDocumento></Ch aveDocumento><DataPrestacao>VALOR</DataPrestacao><StatusNFTS>VALOR</StatusNFTS><Tributaca oNFTS>VALOR</TributacaoNFTS><ValorServicos>VALOR</ValorServicos><ValorDeducoes>VALOR</Val orDeducoes><CodigoServico>VALOR</CodigoServico><CodigoSubItem>VALOR</CodigoSubItem><Aliqu otaServicos>VALOR</AliquotaServicos><ISSRetidoTomador>VALOR</ISSRetidoTomador><ISSRetidoI ntermediario>VALOR</ISSRetidoIntermediario><Prestador><CPFCNPJ><CNPJ>VALOR</CNPJ></CPFCNP J><InscricaoMunicipal>VALOR</InscricaoMunicipal><RazaoSocialPrestador>VALOR</RazaoSocialP restador><Endereco><TipoLogradouro>VALOR</TipoLogradouro><Logradouro>VALOR</Logradouro><N umeroEndereco>VALOR</NumeroEndereco><ComplementoEndereco>VALOR</ComplementoEndereco><Bair ro>VALOR</Bairro><Cidade>VALOR</Cidade><UF>VALOR</UF><CEP>VALOR</CEP></Endereco><Email>VA LOR</Email></Prestador><RegimeTributacao>VALOR</RegimeTributacao><DataPagamento>VALOR</Da taPagamento><Discriminacao>VALOR</Discriminacao><TipoNFTS>VALOR</TipoNFTS><Tomador><CPFCN PJ><CPF>VALOR</CPF></CPFCNPJ><RazaoSocial>VALOR</RazaoSocial></Tomador></tpNFTS> Por outro lado, parece que a comunicação é idêntica. Então, se a estrutura for a mesma, com campos correspondentes, seria possível criar um "Provedor" para a NFTS. Aí seria possível alimentar o ACBrNFSeX com os dados e ele gerar e transmitir. A questão seria avaliar se a estrutura é a mesma e ter alguém disponível para fazer a implementação do "Provedor para NFTS".

Boa tarde. Não... A solução ACBr (seja Lib, Monitor ou componente) verifica as configurações do município e do provedor. Com base nessas configurações ela gera o XML que por sua vez deve atender aos schemas. Isso depende do modelo que eles vão utilizar. Se é um modelo próprio então depende de ajustes. A vantagem é que no momento que ajustamos para um município, geralmente fica tudo certo para todos os outros municípios que utilizam o mesmo provedor e modelo. Como o @Diego Foliene mencionou antes, os ajustes já estão sendo feitos para vários provedores. Na verdade pelo tópico que você linkou no início, os ajustes parecem já terem sido feitos. Vocês não precisariam adicionar porque, no tópico que você citou já tem os schemas. Assim, os schemas vão ser disponibilizados juntamente com a Lib. Então quando eles estiverem disponíveis na Lib vocês podem usá-los. Dito tudo isso, uma coisa vocês precisam ajustar. A emissão do lado de vocês precisará seguir o novo modelo. Nesse sentido, veja se esse tópico ajuda: https://www.projetoacbr.com.br/forum/topic/88289-em-01012026-a-sua-aplicação-de-emissão-de-nfs-e-pode-parar/

Obrigado pelo retorno.

Achei essa outra informação. Parece apontar pra coisa diferente porque tem os dois manuais um para NFS-e e outro para NFTS: https://notadomilhao.sf.prefeitura.sp.gov.br/manuais/

@marciost Criei um chamado no nosso backlog, a saber, ACBR-8607. Obrigado pela contribuição. Assim que possível vamos dar um retorno aqui mesmo.

Olá pessoal, Queremos informar que já está disponível o DACTe feito em FPDF. Uma vantagem desse formato é a geração rápida de um arquivo PDF. Já está disponível no ACBrInstall. E com as próximas compilações da ACBrLibCTe e do ACBrMonitor, deverá estar disponível lá também. Abaixo uma imagem para dar uma ideia de como ficou embora esteja devidamente censurado os dados mais sensíveis (como o código de barras): Como sempre, incentivamos a todos a testarem e nos dar retornos sobre esse novo componente. Bom trabalho e até a próxima!