Diego Foliene

Boa tarde! Temos relatos de alguns colegas que conseguiram gerar algumas notas para teste. Por favor, você está enfrentando algum problema ou dificuldade? Se sim qual? Alguma mensagem de erro?

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde! Por favor, não sei se entendi sua solicitação. Essa propriedade consta na classe ICMSProdutoNFe.cs disponível em nosso SVN, veja:

Olá, comunidade ! Foi liberada a API de consulta ao projeto conformidade fácil. Essa API vai permitir a consulta das tabelas de CST e cClassTrib aplicando filtro por CST. A autenticação será feita através de certificados ICP-Brasil. Recomenda-se que não seja feito muito mais do que um Get diário para obter as informações. Novos recursos serão adicionados gradativamente. O endpoint para comunicação com a API é: https://cff.svrs.rs.gov.br/api/v1/consultas/classTrib Veja a notícia completa em: https://dfe-portal.svrs.rs.gov.br/Cff/Noticias

Olá, comunidade ! Informamos que a propriedade TamanhoPapel foi removida da classe base para os componentes de impressão. Alguns podem receber mensagem semelhante a esta ao abrir seus projetos: Basta clicar em Ignore e salvar o projeto para que ela seja removida do .dfm Por que essa propriedade foi removida? Esta propriedade foi adicionada originalmente para ser utilizada apenas por alguns poucos impressos específicos. Como a maior parte dos impressos tem suas dimensões definidas por regulamentações e manuais de orientação, sua presença estava causando confusão com muitos tentando utilizar ela sem efeitos.

O Problema. Existem diversas soluções ACBr que auxiliam os desenvolvedores no processo de comunicação com os web services disponibilizados pelas Sefaz para a emissão de variados documentos fiscais eletrônicos. Algumas vezes, ao utilizar essas soluções para emissão de notas, alguns podem se deparar com um retorno em branco, como por exemplo: Versão Layout: Ambiente: 2 Versão Aplicativo: Status Código: 0 Status Descrição: UF: SP Recebimento: Tempo Médio: 0 Retorno: Observação: Solução 1 - Dlls da LibXML2 As rotinas que fazem a leitura do arquivo XML que é devolvido pelo web service, possuem uma dependência as Dlls da LibXML2. Se estiver recebendo este retorno em branco, verifique se essas Dlls foram devidamente distribuídas junto a sua aplicação. Para evitar quaisquer dúvidas, você pode colocar elas dentro da pasta do seu .EXE. Caso utilize Linux, é preciso criar um link simbólico. Solução 2 - Classe de resposta Cada método de comunicação com o web service possui uma classe própria para ser preenchida com as informações da resposta. Confira se está lendo as propriedades da classe de resposta correta. Por exemplo, quando o envio é feito de forma síncrona para a NFe, o retorno é preenchido na classe ACBrNFe.WebServices.Enviar.XXX, portanto, se eu ler de ACBrNFe.WebServices.Retorno.XXX as informações estarão em branco. Solução 3 - Eventos de Transmissão Os componentes do ACBr costumam fazer o processo de envio e leitura do retorno automaticamente, mas ele também fornecem a possibilidade de que o desenvolvedor faça esta implementação por conta própria. Ao fazer isso, o componente vai passar essa responsabilidade para o desenvolvedor. Caso esteja recebendo o retorno em branco e queira que o componente ACBr cuide do processo, verifique se os eventos OnTransmit, OnTransmitError e OnTransmitted não foram implementados por engano.

Com o advento da reforma tributária, os municípios são deixados com uma escolha: Aderem ao padrão nacional na íntegra ou continuam usando provedor próprio no formato aderindo ao padrão nacional no formato de compartilhamento de informações. Se escolhida a segunda opção, dois caminhos podem ser seguidos: No caminho mais simples, o provedor cria uma API própria para recepcionar os arquivos XMLs segundo o leiaute do Padrão Nacional. Nesta abordagem, o leiaute utilizado é o já existente do padrão nacional, então basta saber qual é a URL da API para comunicação e os end-points. No caminho mais complexo, o provedor altera o leiaute que ele já usa, adicionando novos campos para receber as informações que ela vai compartilhar posteriormente com o padrão nacional. Padrão Nacional A quantidade de municípios que aderiram ao Padrão Nacional é cada vez maior e pode ser conferida em um Dashboard alimentado e atualizado em tempo real. Acesse o Dashboard AQUI. Lembrando que as soluções ACBr já atendem ao padrão nacional. Provedores com API Própria para atender o Padrão Nacional com a Reforma Tributária. Última atualização: 06/01/2026 Observação: Vale reforçar que devido a relação quantidade de provedores x prazo, o foco das implementações inicialmente tem sido os métodos de emissão da NFS-e. Provedor Requisito Cidade testada Cidades atendidas* Emissão funcionando ABase Informar o Token em WSChaveAcesso Boa Vista do Burica/MS 39 Em testes Betha Vai usar WebService Soap Dourados/MS 403 Envio OK Coplan Vai usar WebService Soap Barra do Garças/MT 31 Em testes Citta Enviar o XML da NFS-e São Valentim do Sul/RS 24 Envio OK Digifred Vai usar WebService Soap Ibirubá/RS 21 Envio OK EL Informar o Token em WSChaveAcesso Aracruz/PE 155 Envio OK Infisc - Campo Bom/RS 9 Envio OK ISSNet WS Soap/Permite Lote de DPS - 25 Aguardando as URLs de homologação Pronim Permite o envio de um lote de DPS Regente Feijó/SP 184 Envio OK RLZ - Barretos/SP 9 - SilTecnologia WS Soap/Enviar o XML da NFS-e Franca/SP 16 Retorno Vazio SimplISS - Blumenau/SC 27 Envio OK (Ainda não aceita os campos IBSCBS) Tiplan - Americana/SP 8 Envio OK * Estimativa aproximada Provedores que alteram o layout em uso para atender a Reforma Tributária. Última atualização: 06/01/2026 Provedor Requisito Cidades Atendidas* Emissão funcionando EloTech Versão 2.03 138 Envio OK FintelISS Versão 2.02 4 O webservice da prefeitura não aplicou o novo Schema GeisWeb Próprio 7 Envio OK Ginfes - 22 Giss - 18 Envio OK IPM - 188 Envio OK ISSBarueri - 1 ISSe - 1 Envio OK ISSSaoPaulo Versão 2.00 1 Envio OK Publica Versão 1.00 31 Envio OK SigISSWeb Próprio 11 Envio OK SpeedGov Versão 2.00 32 Tinus Versão 2.03 44 Envio OK WebISS Versão 2.02 87 Envio OK * Estimativa aproximada

Existem diversos componentes de emissão de documentos fiscais eletrônicos no ACBr. Cada um possui suas particularidades, mas algumas propriedades são comuns para todos eles. Um exemplo disso são as propriedades a seguir que podem ser acessadas no caminho ACBrDFe.Configuracoes.Arquivos. PathSalvar (string): Define o local em que serão salvos todos os arquivos XML gerados pelo componente. PathSchemas (string): Define o local em que se encontram os arquivos de schema, utilizados para validação do arquivo XML antes de seu envio para o web service. IniServicos (string): Define o arquivo .INI que contém as URLs utilizadas pelo componente para comunicação com o web service. Por exemplo, para o componente ACBrNFe, seria o ACBrNFeServicos.ini. Vale mencionar, que se esta propriedade não for preenchida, será usado o resource interno. Salvar (boolean): Define se o componente deve ou não salvar os arquivos XML. AdicionarLiteral (boolean): Faz com que seja criada uma nova subpasta com o literal do tipo de XML ao salvar. Vamos considerar como um exemplo o componente ACBrNFe, com o caminho "C:\MeuSoftware\XMLs\" definido em PathSalvar e o valor true definido em Salvar. Se estiver sendo salvo um arquivo XML de uma nota fiscal eletrônica, modelo 55, será criada uma subpasta "NFe" e o XML será salvo no caminho: "C:\MeuSoftware\XMLs\NFe\". Se estiver sendo salvo um arquivo XML de uma nota fiscal de consumidor eletrônica, modelo 65, será criada uma subpasta "NFCe" e o XML será salvo no caminho - "C:\MeuSoftware\XMLs\NFCe\". SepararPorCNPJ (boolean): Faz com que seja criada uma nova subpasta com o CNPJ do documento ao salvar o arquivo. Vamos considerar como um exemplo o componente ACBrNFe, com o caminho "C:\MeuSoftware\XMLs\" definido em PathSalvar e o valor true definido em Salvar. Se o CNPJ do emissor do XML for 99999999999999, será criada uma subpasta com este nome e o XML será salvo no caminho - "C:\MeuSoftware\XMLs\99999999999999\". SepararPorIE (boolean): Faz com que seja criada uma nova subpasta com a IE do documento ao salvar o arquivo. Vamos considerar como um exemplo o componente ACBrNFe, com o caminho "C:\MeuSoftware\XMLs\" definido em PathSalvar e o valor true definido em Salvar. Se a IE do emissor do XML for 11111111111111, será criada uma subpasta com este nome e o XML será salvo no caminho - "C:\MeuSoftware\XMLs\11111111111111\". SepararPorModelo (boolean): Faz com que seja criada uma nova subpasta com a IE do documento ao salvar o arquivo. Vamos considerar como um exemplo o componente ACBrNFe, com o caminho "C:\MeuSoftware\XMLs\" definido em PathSalvar e o valor true definido em Salvar. Se estiver sendo salvo um arquivo XML de uma nota fiscal eletrônica, modelo 55, será criada uma subpasta "NFe" e o XML será salvo no caminho: "C:\MeuSoftware\XMLs\NFe\". Se estiver sendo salvo um arquivo XML de uma nota fiscal de consumidor eletrônica, modelo 65, será criada uma subpasta "NFCe" e o XML será salvo no caminho - "C:\MeuSoftware\XMLs\NFCe\". SepararPorAno (boolean): Faz com que seja criada uma nova subpasta com o Ano de emissão do documento ao salvar o arquivo. Vamos considerar como um exemplo o componente ACBrNFe, com o caminho "C:\MeuSoftware\XMLs\" definido em PathSalvar e o valor true definido em Salvar. Se estiver sendo salvo um arquivo XML de uma nota emitida em 2025, será criada uma subpasta "2025" e o XML será salvo no caminho - "C:\MeuSoftware\XMLs\2025\". SepararPorMes (boolean): Faz com que seja criada uma nova subpasta com o Mes de emissão do documento ao salvar o arquivo. Vamos considerar como um exemplo o componente ACBrNFe, com o caminho "C:\MeuSoftware\XMLs\" definido em PathSalvar e o valor true definido em Salvar. Se estiver sendo salvo um arquivo XML de uma nota emitida em novembro de 2025 e estiver marcado SepararPorAno, será criada uma subpasta "11" e o XML será salvo no caminho - "C:\MeuSoftware\XMLs\2025\11". Caso não esteja marcado SepararPorAno, será criada uma subpasta "202511" e o xML será salvo no caminho - "C:\MeuSoftware\XMLs\202511". SepararPorDia (boolean): Faz com que seja criada uma nova subpasta com o Dia de emissão do documento ao salvar o arquivo. Para que esta configuração seja aplicada SepararPorMes deve estar marcado. Vamos considerar como um exemplo o componente ACBrNFe, com o caminho "C:\MeuSoftware\XMLs\" definido em PathSalvar e o valor true definido em Salvar. Se estiver sendo salvo um arquivo XML de uma nota emitida no dia 17, será criada uma subpasta "17" e o arquivo XML será salvo no caminho - "C:\MeuSoftware\XMLS\202511\17" OrdenacaoPath (collection): Usada para definir qual é a ordem que deve ser considerada para gerar as subpastas caso mais de uma das configurações de separação tenha sido definida. Faz com que seja criada uma nova subpasta com a IE do documento ao salvar o arquivo. Vamos considerar como um exemplo o componente ACBrNFe, com o caminho "C:\MeuSoftware\XMLs\" definido em PathSalvar, o valor true definido em Salvar e o valor true definido para SepararPorModelo, SepararPorCNPJ e SepararPorIE. Ao salvar o arquivo, você pode usar o OrdenacaoPath para definir que o caminho com as subpastas seja "C:\MeuSoftware\XMLs\CNPJ\IE\Modelo" ou "C:\MeuSoftware\XMLs\Modelo\CNPJ\IE".

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde! A versão 1.30 da Nota Técnica 2025/002 (versão mais recente publicada até o momento), postergou a entrada dos schemas no ambiente de produção para 10/11/2025.

Olá, comunidade ! Foi adicionado a partir de 08/10/2025 no sistema do e-Social uma nova validação relacionada aos descontos de empréstimo consignado. Ao enviar os eventos S-1200, S-2299 e S-2399, será validado se existe um contrato de empréstimo consignado ativo com parcela prevista para a competência da remuneração enviada e se a instituição financeira e o número do contrato enviados estão corretos. Possíveis mensagens de retorno em caso de divergência serão: 1988 - O trabalhador <<cpfTrab>>, matrícula <<matricula>> possui parcela(s) de empréstimo consignado do Programa Crédito do Trabalhador prevista para desconto na competência de apuração <<MM/AAAA>>. No entanto, o empregador informou os dados incorretos ou não informou rubrica de desconto do empréstimo neste evento. Verifique a informação correta no arquivo disponibilizado no Portal Emprega Brasil e retifique este evento. Foram localizados os seguintes contratos de empréstimo consignado com previsão de pagamento de parcela nesta competência: Instituição Financeira: <<instFinanc>>, Contrato <<nrDoc>> | Instituição Financeira: <<instFinanc>>, Contrato <<nrDoc>> 1989 - O usuário informou rubrica de desconto do empréstimo consignado neste evento para o trabalhador <<cpfTrab>>, matrícula <<matricula>> que não possui parcela(s) do Programa Crédito do Trabalhador prevista para desconto na competência de apuração <<MM/AAAA>>. Verifique a informação correta no arquivo disponibilizado no Portal Emprega Brasil e retifique este evento. 1990 - O usuário informou rubrica de desconto do empréstimo consignado neste evento, mas a validação não pode ser realizada na base do Programa Crédito do Trabalhador. Certifique-se que os valores estão corretos no arquivo disponibilizado no Portal Emprega Brasil. Leia a notícia original completo AQUI. Lembrando que o ACBreSocial, o ACBrMonitorPLUS e a ACBrLib são compatíveis com o eConsignado.

Olá, comunidade ! Foi publicado no 10/10/2025 o Correio Eletrônico Circular SEF/DIAT/Nº 24 / 2025 reforçando que a partir de 01/11/2025 será obrigatória a emissão da NFCom modelo 62 em substituição aos documentos fiscais modelo 21 e modelo 22 pelos contribuintes no estado. Também é informado que a partir de outubro a Sefaz iniciou o credenciamento de ofício para os contribuintes prestadores de serviço de comunicação que ainda não haviam solicitado credenciamento voluntario e que os mesmos tem o prazo de 90 dias a partir de 1º de novembro para regularizar quaisquer pendências quanto ao DTEC (domicílio tributário eletrônico) e AUPD (autorização de uso de sistema eletrônico de processamento de dados). Leia o correio eletrônico circular completo AQUI.

Olá, comunidade ! Foi publicado no Diário Oficial da União o DESPACHO Nº 33, DE 8 DE OUTUBRO DE 2025, efetivamente adicionando a necessidade da geração de um MDF-e por UF unidade federada. Fazem parte deste Despacho, dentre outros, os Ajustes Sinief relacionados abaixo. O AJUSTE SINIEF Nº 27, de 3 de Outubro de 2025 altera o Altera o Ajuste SINIEF nº 21, de 10 de dezembro de 2010 que institui o MDF-e, modificando a redação do § 2º da cláusula terceira para: Este mesmo ajuste também acrescenta o § 2º-A na mesma cláusula:

Olá, comunidade ! Foi publicado no Diário Oficial da União o DESPACHO Nº 33, DE 8 DE OUTUBRO DE 2025, efetivamente permitindo que as UFs posterguem a data de obrigatoriedade da NFCom considerando critérios específicos. Fazem parte deste Despacho, dentre outros, os Ajustes Sinief relacionados abaixo. O Ajuste SINIEF Nº 25, de 3 de Outubro de 2025 altera o Ajuste SINIEF nº 7, de 7 de abril de 2022 que institui NFCom acrescendo o § 5º a cláusula primeira: Vale ressaltar, no entanto, que apesar desta publicação, ainda não foi publicado nada específico pelos estados, fazendo uso dessa nova cláusula e postergando a data de obrigatoriedade, portanto, até o momento, mantem-se a data de 01/11/2025

Olá, comunidade ! Ao acessar a seção de Avisos nos Portais de Documentos Fiscais da Sefaz Virtual do Rio Grande do Sul (SVRS), observamos um comunicado importante. Visando coibir o uso indevido das informações para a criação de Data Lakes e o treinamento de Inteligências Artificiais (IAs), a SVRS implementou novas regras de autenticação. O login para Pessoas Jurídicas será feito exclusivamente via e-CNPJ, enquanto o acesso para Pessoas Físicas será realizado através da plataforma Gov.br. Esta medida substitui o uso do Recaptcha, que estava perdendo sua eficácia contra rotinas automatizadas. O aviso também pode ser lido na íntegra direto da fonte AQUI.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia! Efetuado teste utilizando o programa exemplo do ACBrNFSeX em produção. Resultado: Como não tenho dados válidos para emissão, uma rejeição era esperada. Por favor, caso o problema ainda persista, veja se seus fontes estão atualizados e em dia com o SVN e caso utilize a LibNFSe ou o ACBrMonitorPLUS, atualize para a versão mais recente. Veja também se não possui arquivo ACBrNFSeXServicos.ini defasado junto a sua aplicação.

Adiado para janeiro de 2026 (veja informações completas no tópico abaixo):

Olá comunidade ! Foi publicado no Diário Oficial da União o DESPACHO Nº 33, DE 8 DE OUTUBRO DE 2025, efetivamente postergando a entrada em vigor do fim da NFCe para CNPJ para 05/01/2026. Fazem parte deste Despacho, dentre outros, os Ajustes Sinief relacionados abaixo. O Ajuste SINIEF Nº 28, de 3 de Outubro de 2025 altera o Ajuste SINIEF Nº 12 de 29 de Abril que definiu as modificações feitas na NFe para ser usada no lugar da NFCe para CNPJ, efetivamente mudando sua cláusula que define sua entrada em vigor para: O Ajuste SINIEF Nº 30, de 3 de Outubro de 2025 altera o Ajuste SINIEF Nº 11 de 29 de Abril que definiu a proibição da NFCe para CNPJ, efetivamente mudando sua cláusula que define sua entrada em vigor para:

Olá comunidade ! Recebemos a informação de alguns membros da comunidade de que a situação foi normalizada no ambiente de São Paulo.

Contexto Esta rejeição foi adicionada pela Nota Técnica 2025/001 e obriga o preenchimento das informações de pagamento no MDFe quando for realizado carga de lotação. O que é carga lotação? Carga lotação, as vezes chamada de carga fechada, é a operação em que o transporte das mercadorias de um único remetente ocupa toda a capacidade do veículo. Resolução Se você estiver recebendo esta rejeição ao tentar emitir o MDFe, você deve gerar o grupo InfPag que possui as informações de pagamento em seu arquivo XML. Caso utilize componente nativo para Delphi/Lazarus: uses ACBrMDFe.Classes; var lMDFe: TMDFe; lInfPag: TinfPagCollectionItem; lComp: TCompCollectionItem; lInfPrazo: TInfPrazoCollectionItem; begin lMDFe := ACBrMDFe.Manifestos.Add; //Preenchimento das demais informações do MDFe. lInfPag := lMDFe.rodo.infANTT.infPag.New; lInfPag.xNome := //String; lInfPag.idEstrangeiro := //String; lInfPag.CNPJCPF := //String; lInfPag.vContrato := //Double; lInfPag.indAltoDesemp := //TIndicador = (tiSim, tiNao); lInfPag.indPag := //TIndPag = (ipVista, ipPrazo); lInfPag.vAdiant := //Double; lInfPag.indAntecipaAdiant := //TIndicador = (tiSim, tiNao); lInfPag.tpAntecip := // TtpAntecip = (taNenhum, taNaoPermiteAntecipar, taPermiteAntecipar, taPermiteAnteciparComConfirmacao); lInfPag.InfBanc.codBanco := //String; lInfPag.InfBanc.codAgencia := //String; lInfPag.InfBanc.CNPJIPEF := //String; lInfPag.InfBanc.PIX := //String; lComp := lInfPag.Comp.New; lComp.tpComp := //TComp = (tcValePedagio, tcImpostos, tcDespesas, tcFrete, tcOutros); lComp.vComp := //Double; lComp.xComp := //String; lInfPrazo := lInfPag.infPrazo.New; lInfPrazo.nParcela := //Integer; lInfPrazo.dVenc := //TDateTime; lInfPrazo.vParcela := //Double; end; Caso utilize ACBrMonitorPLUS ou ACBrLib: [infPag001] CNPJCPF= xNome= idEstrangeiro= vContrato= indAltoDesemp= indPag= vAdiant= indAntecipaAdiant= tpAntecip= [Comp001001] tpComp= vComp= xComp= [infPrazo001001] nParcela= dVenc= vParcela= [infBanc001] CNPJIPEF= codBanco= codAgencia=

Olá comunidade ! No dia 06/10/2025, por volta das 08H19, começamos a receber relatos em nossa comunidade do Discord de membros recebendo rejeição ao tentar autorizar NFCe em alguns estados para o ambiente de homologação. Os relatos tem em comum a mesma rejeição: UFs cujo problema foi relatado até o momento: SP, MG, GO e PR. Esta rejeição está relacionada a Reforma Tributária sobre o Consumo, foi adicionada a partir da Nota Técnica 2025/002 e na versão 1.30, que é sua publicação mais recente, sua implementação foi postergada sem data definida no ambiente de homologação. Portanto, tudo indica que algumas Sefaz autorizadoras adiantaram a implementação da regra ou implementaram considerando cronograma de versão anterior da nota técnica. Os relatos confirmam ainda que os CRTs 1, 2 e 4 estão sendo tratados como CRT 3 exigindo as informações e também que até o momento desta publicação, apenas o modelo 65 está devolvendo a rejeição, com a NFe modelo 55 aceitando sem os campos. Caso esteja enfrentando problemas, como o relato foi no ambiente de homologação a sugestão é que abra um Fale Conosco junto a Sefaz relatando a questão. Também é importante lembrar que a rejeição pode ser sanada, caso os campos da reforma tributária sejam informados no arquivo XML.