Painel de líderes

Coordenação Técnica do ENCAT 16/06/2025 Consulta Tabelas CST, cClass e Credito Presumido para Reforma Tributária As notas técnicas que preveem a criação da estrutura de dados para alimentar a tributação relativa à Reforma Tributária do Consumo estão publicadas no portal e já existem prazos para a implantação desta versão no ambiente de homologação até do dia 28 de julho de 2025 para NFe, NFCe, BPe, CTe, NF3e e NFCom. Todas as Notas Técnicas apresentam regras de validação que fazem referências as tabelas de CST, Classificação Tributária e Crédito Presumido e seus indicadores (flags) que obrigam ou vedam o preenchimento dos diversos grupos de informações no XML do Documento Fiscal. Visando faciliar o entendimento da aplicação prática destas regras de validação, e sobretudo, trazer dados mais concretos de que forma os ambientes de autorização dos documentos fiscais trabalharão as validações, estamos publicando na forma de consulta deste portal o acesso visual a estas tabelas. Tabelas de CST e cClass: https://dfe-portal.svrs.rs.gov.br/DFE/TabelaClassificacaoTributaria Tabela de Crédito Presumido: https://dfe-portal.svrs.rs.gov.br/DFE/TabelaCreditoPresumido IMPORTANTE: O trabalho de levantamento de situações, aderência à legislação e prospecção de regras de validação, assim como a própria composição destas tabelas é um trabalho em constante revisão e aprimoramento, o que pode resultar em modificações nestas informações. Uma vantagem importante é que a estas tabelas estão acessando o motor de validação em banco de dados, o mesmo que o sistema de autorização da SVRS estará utilizando. Qualquer alteração nas tabelas refletirá imediatamente nas consultas do portal e na validação das regras dos documentos fiscais eletrônicos.

Olá Pessoal, Se encontra disponível desde 21/05/2025 a unit ACBrDFe.Conversao. Essa unit contem os tipos, enumerados e as funções de conversão utilizados pela Reforma Tributária. Sendo assim na unit da sua aplicação que se utiliza dos enumerados e das funções se faz necessário declarar a unit ACBrDFe.Conversao no uses.

Coordenação Técnica ENCAT 01/07/2025 Implantação das Notas Técnicas Reforma Tributária Comunicamos aos contribuintes emitentes de CTe, BPe, NF3e e NFCom que as respectivas Notas Técnicas 2025.001, que implementam o leiaute e regras de validação da reforma tributária, encontram-se IMPLANTADAS no ambiente de homologação da Sefaz virtual RS. Desta forma, as empresas ja podem testar seus sistemas de forma antecipada. Importante destacar que as NTs implantam os campos novos da reforma que serão validados APENAS se forem informados. Caso seja enviado um DFe com o schema anterior, este será validado normalmente. Esta iniciativa visa permitir que possam ser testados os sistemas dos contribuintes e do próprio ambiente de autorização que estará em constante evolução e verificação durante o processo de amadurecimento das publicações das notas técnicas.

Olá pessoal! Como sabem, os fontes do ACBr estão passando por um processo de migração, onde as units da pcn estão sendo substituídas pelas units baseadas nas classes ACBrXMLDocument que fazem uso da LibXML2 O tópico intitulado "ATENÇÃO: ACBr está adotando as classes baseadas em ACBrXMLDocument como padrão!" traz uma explicação mais detalhada, vinculando inclusive uma edição do Papo PRO ACBr que foi realizada tratando sobre a migração. Mas resumindo em poucas palavras, as novas classes trazem um ganho de performance considerável na leitura de arquivos XML que possuem um conteúdo muito extenso, o que de acordo com o leiaute de alguns DFes é uma possibilidade. Um exemplo bem simples é a NFe\NFCe que permite até 990 itens. Este processo está sendo feito por etapas: A primeira etapa foi a mudança das classes de escrita e leitura do arquivo XML, esta etapa foi concluída. A segunda etapa é a troca de algumas units da pcn, por units próprias do ACBr, esta etapa também foi concluída. Estamos entrando agora na próxima etapa que é a mudança dos tipos. Esta etapa envolve a mudança dos tipos TpcnXXX para os tipos TACBrXXXX O processo foi iniciado no MDFe com a alteração do TpcnTipoAmbiente presente na unit pcnConversao para TACBrTipoAmbiente presente na ACBrXmlBase. Acompanhe este tópico para ficar para se manter informado sobre esta mudança. Componentes de Documentos Fiscais Eletrônicos que serão afetados: ACBrBPe ACBrMDFe (Em processo de alteração) ACBrNFe ACBrCTe ACBrDCe ACBrGNRe ACBrGTIN ACBrNF3e ACBrNFCom

Olá pessoal, tivemos uma reunião com uma equipe de Boleto do Itau e vamos esclarecer alguns pontos: Itau existe 2 produtos distintos: “Boletos” – Boleto com linha digitável e código barras; “Bolecode” – Boleto com QrCODE, linha digitável e código barras (hibrido); Todos “Boletos” quando liquidados (linha digitável, código barras) , são listados na API de Consulta Liquidados com status de Liquidados; Todos “Bolecodes” quando liquidados através do qrcode, eles são *Cancelados e são listados na API de Consulta Baixados com status “BL” (Bolecode Liquidado). * (Bolecode Baixado) Isso para evitar que o mesmo boleto seja pago por outro meio. Nas consultas de LIQUIDADOS da solução ACBrBoleto, necessário realizar 02 (duas) consultas, mudando apenas a propriedade "IndicadorPIX": - Consulta Boletos Liquidados via Linha Digitável ou Código de Barras (independente se bolecode ou boleto comum): IndicadorSituacaoBoleto = isbBaixado e IndicadorPix = False - Consulta Boletos Liquidados via QrCode: IndicadorSituacaoBoleto = isbBaixado e IndicadorPIX = True Atenção, informação importante para quem usa Bolecode (Boleto Hibrido) API/CNAB Quando boleto é liquidado através do QrCODE até a presente data não devolve informações sobre pagamento, juros, multa, desconto. (não foi possível agrupar a consulta devida a paginação de repostas de cada endpoint)

Olá Pessoal Os componentes ACBrBPe, ACBrCTe, ACBrDCe, ACBrMDFe, ACBrNF3e, ACBrNFCom e ACBrNFe passam a ter a seguinte assinatura no referido método: procedure EnviarEmail(const sPara, sAssunto: String; sMensagem: TStrings = nil; EnviaPDF: Boolean = True; sCC: TStrings = nil; Anexos: TStrings = nil; sReplyTo: TStrings = nil; ManterPDFSalvo: Boolean = True; sBCC: Tstrings = nil); Os novos parâmetros: ManterPDFSalvo: Se não informado assume o valor padrão True, neste caso o PDF do Documento Auxiliar anexado no e-mail vai ser salvo no disco. Caso você não deseja que o PDF seja salvo em disco, deve-se informar o valor False para esse parâmetro. sBCC: permite informar o endereço de e-mail para ser enviado com cópia oculta. O componente ACBrNFSeX já tem o parâmetro ManterPDFSalvo a um bom tempo, agora ele passa a ter o parâmetro sBCC, portanto a assinatura do método EnviarEmail passa ser padrão para todos os DF-e relacionados nessa postagem. A implementação dos novos parâmetros já se encontra no SVN.

Foi publicada a versão 25.2.A das tabelas fornecidas pelo IBPT, às quais já se encontram também em nosso SVN. As novas tabelas tem a vigência de 20/06/2025 até 31/07/2025. Para cumprimento da Lei 12.741/12, também conhecida como "De Olho no Imposto", não se esqueça de realizar a atualização de seus clientes. Fonte: De Olho no Imposto

Olá pessoal, Gostaria de informar que o PIX Automático já está disponível nos fontes do componente ACBrPIXCD! Com isso, as software houses que utilizam o ACBrPIXCD poderão implementar as jornadas do PIX Automático diretamente em suas aplicações, aproveitando os novos endpoints e recursos disponibilizados pelo BACEN. Sendo necessária apenas a disponibilização dessa funcionalidade na API de cada PSP. Informações Importantes Disponível APENAS para contas PJ (Empresas); É automático APENAS para o PAGADOR. Ou seja, o recebedor deverá gerar a cobrança(/cobr) à cada recorrência; Periodicidades disponíveis: Semanal, Mensal, Trimestral, Semestral e Anual. O BACEN definiu 5 jornadas diferentes, da seguinte forma: Dessas 5 jornadas, será possível utilizar o componente ACBrPIXCD nas 4 primeiras. Descritivo das Jornadas: 1ª Jornada - Ativação da recorrência através de notificação push Criar a recorrência: // Popular objeto ACBrPixCD1.PSP.epRec.RecorrenciaSolicitada ACBrPixCD1.PSP.epRec.CriarRecorrencia Disparar a solicitação da recorrência (notificação push): // Popular objeto ACBrPixCD1.PSP.epSolicRec.SolicitacaoSolicitada ACBrPixCD1.PSP.epSolicRec.CriarSolicitacaoConfirmacao 2ª Jornada - Ativação após pagamento de QR Code gerado na criação da Recorrência Criar o location: ACBrPixCD1.PSP.epLocRec.CriarLocation Criar a recorrência informando o location: // Popular objeto ACBrPixCD1.PSP.epRec.RecorrenciaSolicitada ACBrPixCD1.PSP.epRec.RecorrenciaSolicitada.loc := ID_Location; // IMPORTANTE ACBrPixCD1.PSP.epRec.CriarRecorrencia Consultar a recorrência para obter o “copia e cola”: ACBrPixCD1.PSP.epRec.ConsultarRecorrencia(IDRecorrencia); wQRCode_Gerado := ACBrPixCD1.PSP.epRec.RecorrenciaCompleta.dadosQR.pixCopiaECola; // CopiaECola gerado para pagamento e ativação da recorrência Observação: O QR Code gerado será válido enquanto a recorrência estiver ativa. 3ª Jornada – Ativação após pagamento de cobrança imediata (/cob) Criar a cobrança imediata: // Popular o objeto ACBrPixCD1.PSP.epCob.CobSolicitada ACBrPixCD1.PSP.epCob.CriarCobrancaImediata Criar a recorrência informando o txid da cobrança no objeto ativação: // Popular objeto ACBrPixCD1.PSP.epRec.RecorrenciaSolicitada ACBrPixCD1.PSP.epRec.RecorrenciaSolicitada.ativacao.dadosJornada.txid := txid_Cob; // IMPORTANTE ACBrPixCD1.PSP.epRec.CriarRecorrencia; Consultar a recorrência usando o idRec: ACBrPixCD1.PSP.epRec.ConsultarRecorrencia(IDRec); 4ª Jornada – Ativação após pagamento de cobrança com vencimento (/cobv) Criar a cobrança com vencimento: // Popular objeto ACBrPixCD1.PSP.epCobV.CobVSolicitada ACBrPixCD1.PSP.epCobV.CriarCobranca(txID); Criar a recorrência informando apenas o location (sem txid): // Popular objeto ACBrPixCD1.PSP.epRec.RecorrenciaSolicitada ACBrPixCD1.PSP.epRec.RecorrenciaSolicitada.loc := Loc_CobV; // IMPORTANTE ACBrPixCD1.PSP.epRec.CriarRecorrencia; Consultar a recorrência com idRec: ACBrPixCD1.PSP.epRec.ConsultarRecorrencia(IDRec); Como usar? Para utilizar as jornadas acima, basta atualizar os fontes do ACBr e consultar os novos métodos e propriedades disponíveis no componente ACBrPIXCD. As aplicações de demonstração do componente também já estão atualizadas com as novas funcionalidades. Qualquer dúvida ou sugestão, só comentar por aqui ou acessar nosso SERVIDOR NO DISCORD. Bons códigos a todos!

Pessoal, estou criando esse tópico para alertar sobre esse assunto. Parece que tem gente que ainda não sabe sobre essa situação e o tempo já vai acabando. Veja a notícia abaixo que é do ano passado: Se ainda não fez isso, comece logo a implementar a NFC-e. Lembre-se que ano que vem já entra também a Reforma Tributária. Os usuários ACBr PRO podem contar com a ajuda de nossos cursos como a Masterclass sobre o SAT, o curso Dominando NFC-e e também o curso NFC-e Offline.

Olá, pessoal! No dia 04/07/2025, por volta das 14h12, começamos a receber diversos relatos de membros da nossa comunidade, tanto em nosso servidor do Discord quanto em nosso fórum, sobre problemas relacionados à NF-e e à NFC-e junto a Sefaz sefaz de múltiplas UFs. Todos os relatos tinham em comum a mesma situação: o número do protocolo de autorização (nProt) devolvido pelos web services continha 17 caracteres, em vez dos habituais 15. Se conferirmos na Nota Técnica 2025/002, podemos observar que, de fato, está previsto um aumento de 15 para 17 caracteres nesta informação. No entanto, ainda não alcançamos as datas previstas no cronograma para esta implementação. De acordo com alguns relatos, essa questão foi sanada e, após pouco tempo, as notas autorizadas voltaram a apresentar o nProt com tamanho 15. Contudo, ainda temos relatos de problema, pois algumas notas que foram geradas com protocolo de 17 caracteres estão devolvendo erro de schema ao tentar cancelar: Falha na validação dos dados do Evento: --> 1839 - Element '{http://www.portalfiscal.inf.br/nfe%7DnProt': [facet 'pattern'] The value '3XXXX0000003XXXX2' is not accepted by the pattern '[0-9]{15}'. Considerando todas essas informações: Caso esteja enfrentando erro de schema ao tentar realizar o cancelamento dessas notas, confirme se não está utilizando arquivo de schema desatualizado, pois a regex já foi atualizada nos arquivos .XSD em pacote de schemas liberado anteriormente para a Reforma Tributária. ...\trunk2\Exemplos\ACBrDFe\Schemas\NFe\tiposBasico_v4.00.xsd <xs:simpleType name="TProt"> <xs:annotation> <xs:documentation>Tipo Número do Protocolo de Status</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:whiteSpace value="preserve"/> <xs:maxLength value="17"/> <xs:pattern value="[0-9]{15}|[0-9]{17}"/> </xs:restriction> </xs:simpleType> Caso ainda esteja recebendo o nProt com tamanho 17 ao autorizar uma NFe/NFCe ou esteja recebendo erro diferente do mencionado acima ao tentar cancelar essas notas, recomendamos que abra um Fale Conosco junto a Sefaz para relatar a situação. Quanto mais pessoas reportarem, mais rápido a respectiva Sefaz perceberá que existe algum problema. Para abrir um Fale Conosco junto a Sefaz, siga as orientações de acordo com a Sefaz de sua Jurisdição

Olá pessoal! A partir de 30/06/2025 o web service do e-Social vai implementar em seus servidores de recepção e consulta de lotes de eventos um novo certificado visando adotar um padrão de segurança mais robusto baseado algoritmo SHA-384 combinado com RSA. Aplicações que não suportem essa configuração poderão apresentar falhas de conexão. O ACBr está pronto para esta mudança? A equipe de consultores está analisando as informações disponibilizadas e avaliando os fontes para confirmar se existe necessidade de alguma alteração nos fontes do ACBr. Assim que houver novas informações este tópico será atualizado Este tópico foi baseado em notícia publicada originalmente AQUI.

Olá pessoal! A versão 3.0 do QrCode da NFCe foi introduzida na Nota Técnica 2025/001 (leia mais sobre ela AQUI), onde a data de implementação no ambiente de homologação é 02/06/2025. No entanto, mesmo tendo passado está data, temos recebido alguns relatos de membros da comunidade que receberam erro de falha no schema ao tentar gerar NFCe com o QrCode na versão 3.0 para estados como São Paulo ou Goias. Para o estado de Goias, o membro de nossa comunidade @Silvair L Soares compartilhou a seguinte informação de que a implementação está programada para 13/06/2025: Caso esteja enfrentando problemas junto a Sefaz de São Paulo, entre em contato com a mesma para questionar se também não houve atraso na implementação.

Olá comunidade do Projeto ACBr ! Agora é possível utilizar as classes de alto nível referente a reforma tributária. Realizamos uma atualização das classes, onde o mesmo já esta disponíveis em nosso SVN - Commit (39575, 39576). Commit At revision: 39575: -> Foram adicionadas novas classes referente a reforma tributária. Commit At revision: 39576: -> Atualização do programa exemplo, incluindo exemplo de preenchimento usando as novas classes da reforma tributária. Para utilizar as novas classes, é necessário atualizar ACBrLibNFe.aar para a versão disponível a partir de 10/06/2025, além de atualizar os fontes disponíveis no SVN. É necessário também atualizar a pasta Schemas da NFe pois a ultima versão disponível já contem os .xsds da a reforma tributária. Detalhe, a liberação do ambiente de homologação esta previsto para o dia 01/07/2025. O Projeto ACBr esta centralizando todas as informações no tópico abaixo: Aguardamos feedbacks. Até a próxima.

Olá Pessoal, A cidade de Araraquara/SP trocou de provedor, deixou de usar o Ginfes e passou a usar o Giap. O provedor Ginfes se utiliza da versão 1 do layout da ABRASF e o Giap possui um layout próprio. O provedor Giap já se encontra implementado a um bom tempo e é usado por exemplo pela cidade de São Carlos/SP. A principio foi feita a alteração no arquivo ACBrNFSeXServicos.ini visando a troca do provedor e as URL de homologação e produção. Mas isso não foi suficiente, pois o provedor Giap vai utilizar a versão 1 do layout da ABRASF para Araraquara/SP. Sendo assim foi necessário realizar alterações no código do componente, mais precisamente nas units referente ao provedor Giap para poder atender essa demanda. Quais foram as alterações que devemos prestar mais atenção? Quem costuma copiar o arquivo ACBrNFSeXServicos.ini para a maquina do emitente da nota, vai ter que atualizar. Temos uma nova pasta de esquemas: A pasta 1.00 contem os schemas do provedor Giap para o seu layout próprio. A pasta 1.01 contem os schemas para o provedor Giap validar o XML do RPS segundo a versão 1 do layout da ABRASF. Uma nova versão do ACBrLibNFSe e do ACBrMonitor Plus já esta sendo providenciada ainda para hoje 06/06/2025. Caso alguém tenha algum problema com os serviços disponibilizados pelo provedor favor criar um tópico aqui no fórum e relatar o problema. Por fim quero informa-los que o provedor Giap disponibiliza os serviços: Recepcionar um lote com até 50 RPS, Consultar NFSe por RPS e Cancelar NFS-e. Somente esses 3 serviços estão disponíveis no webservice do provedor.

SEFAZ Virtual RS 04/07/2025 Urgente – Número de protocolo com 17 caracteres na SVRS O retorno de 17 caracteres para o número de protocolo será adotado pela SEFAZ-SP, futuramente (ainda sem previsão), devido ao alto volume de emissão de NFC-e por ano, conforme previsto na Nota Técnica 2025.002 (NT da Reforma Tributária). Equivocadamente, esse retorno entrou em produção para a Sefaz Virtual do Rio Grande do Sul (SVRS) hoje (04/07/2025, entre 13h39 e 14h45), afetando a informação da autorização de uso para parte dos sistemas ERP. A SVRS já fez a correção no WebService de “Consulta Situação” para retornar o número do protocolo com 15 caracteres. Assim, a solução para as NF-e emitidas no horário supracitado é realizar novamente a consulta dos números de protocolo, retornando com o número de 15 caracteres. Sobre o evento de cancelamento, nas próximas horas, será liberada a versão aceitando o pedido de cancelamento com o número do protocolo contendo 15 ou 17 caracteres, considerando que muitas empresas internalizaram o protocolo com 17 caracteres. Contamos com a compreensão de todos. Orientação da Equipe ACBr: Atenção Pessoal, quem guarda no banco de dados o numero do protocolo de autorização do DF-e bem como o numero de autorização dos eventos, deverá realizar uma alteração de tamanho nas tabelas que guardam o numero do protocolo, alterando o tamanho de 15 para 17, não esqueçam de fazer isso.

Olá pessoal! No dia 26/06/2025 foi publicada a versão 1.01 desta nota técnica. Alterações Aumenta o tamanho máximo do campo QrCode para permitir até 1000 caracteres para coincidir com os arquivos de schema já disponibilizados anteriormente. A regra de validação que devolve a mensagem "805 - A SEFAZ do destinatário não permite Contribuinte Isento de Inscrição Estadual" foi atualizada para incluir a lista de UFs conforme texto: Remove a regra de validação que devolve a mensagem "407 - NFC-e com qrCode na versão 3". Datas A nova versão da nota técnica não altera as datas previstas em versão anterior, portanto, permanecem sendo as mesmas. Implantação Teste: Até 02/06/2025 Implantação Produção: Até 01/09/2025 E como fica o ACBr? A nova versão apenas corrige o texto na NT para se adequar ao esquema que já estava correto e foi utilizado como base na implementação feita no ACBr e altera regras de validação, portanto, ajustes nas soluções ACBr não se fazem necessários. Leia a versão 1.01 desta nota técnica na íntegra AQUI.

Olá pessoal! Crio este tópico para alertar aqueles que não sabem e relembrar aqueles que possam ter esquecido, de que o envio de lote de NFe contendo somente um documento no lote já não pode ser feito de maneira assíncrona no ambiente de homologação desde 02/06/2025. Com previsão de ser abolido no ambiente de produção em 01/09/2025! O fim dessa forma de envio para esta situação específica foi decretado na Nota Técnica 2025/001: Aqueles que tentarem realizar o envio de um lote contendo somente 1 NFe de maneira assíncrona, depois dessas datas vão receber uma rejeição: Veja o tópico abaixo para uma explicação mais detalhada sobre a rejeição: Veja este tópico para uma orientação sobre como realizar o envio de forma síncrona e como ler o retorno, que é devolvido em outra classe quando envio síncrono, usando o componente:

Olá pessoal! Foi publicado no dia 11/06/2025 a Nota Técnica 02/2025 para o EFD-Reinf. A mesma traz alterações no evento R-1000 adicionando um novo campo opcional indPertIRRF para servir como indicador de pertencimento ao IRRF. O novo campo é de preenchimento exclusivo para o contribuinte cuja natureza jurídica seja igual a [126-0, 127-9, 129-5, 130-9]. E como fica o ACBr? Foi criada a #TK-7221 para adequação do componente adicionando o novo campo. Qualquer novidade será divulgada aqui neste tópico. Leia a nota técnica na íntegra AQUI ou em nosso Tools

Olá pessoal, Foram enviados, na Rev-39761, os ajustes necessários para atender à NT 02/2025. Foram atualizados também os schemas: http://sped.rfb.gov.br/arquivo/download/7813

Olá pessoal! Foi publicado no dia 11/06/2025 o Informe Técnico 2025.003 para divulgar o novo endereço de consulta da NFC-e para geração do QrCode que é impresso no DANFCe. Esta URL é utilizada para montar a string que é informada na tag qrCode do XML da NFC-e, devolvendo rejeição 395 - Endereço do site da UF da Consulta via QR-Code diverge do previsto caso esteja incorreta. UF URL Vigência GO Produção http://nfe.sefaz.go.gov.br/nfeweb/sites/nfce/danfeNFCe Até 30/08/2025 https://nfeweb.sefaz.go.gov.br/nfeweb/sites/nfce/danfeNFCe A partir de 16/06/2025 GO Homologação http://homolog.sefaz.go.gov.br/nfeweb/sites/nfce/danfeNFCe Até 30/06/2025 https://nfewebhomolog.sefaz.go.gov.br/nfeweb/sites/nfce/danfeNFCe A partir de 16/06/2025 E como fica o ACBr? Foi criada a #TK-7211 para atualização das URLs conforme cronograma definido no informe. Leia o Informe Técnico na íntegra AQUI.

Olá pessoal! Conferindo no painel Situação SVC-RS, é possível observar que a Sefaz de Goais ativou a contingência às 08h30 do dia 10/06/2025, com previsão de permanecer ativada até às 17h00 do mesmo dia. Para utilizar as soluções do ACBr em contingência durante este período siga as orientações do tópico abaixo:

Olá pessoal! Foi publicado o Correio Eletrônico Circular SEF/DIAT/Nº 10 / 2025 definindo o uso obrigatório da Nota Fiscal de Fatura de Serviços de Comunicação Eletrônica (NFCom) para o estado de Santa Catarina em 01/11/2025. Todas as empresas prestadoras de serviço de comunicação já estão credenciadas no ambiente de homologação podendo realizar seus testes. A solicitação de credenciamento voluntário no ambiente de produção (disponível desde 1º de dezembro de 2023) deverá ser feita pelo contabilista da empresa no Sistema de Administração Tributária-S@T, através da aplicação CEI – Gerenciamento de Autorização para Utilização de Processamento de Dados (AUPD), observando os artigos 2° e 7°-C, do Anexo 7 ao RICMS/SC, o ATO DIAT n° 31/2023, o ATO DIAT nº 32/2023, ATO DIAT 13/2025 e o ATO DIAT nº 44/2023. Vale lembrar que o ACBr possui o componente ACBrNFCom disponível para Delphi e Lazarus para emissão da NFCom. O exemplo do mesmo pode ser encontrado em ..\trunk2\Exemplos\ACBrDFe\ACBrNFCom

Olá pessoal! Foi compartilhado em nossa comunidade o seguinte comunicado relacionado ao município de São Jose do Rio Preto/SP: Portanto, se você estiver enfrentando algum problema para emitir NFSe para este município, é possível que seja devido a essa indisponibilidade.

Olá Pessoal, Vamos atualizar esse tópico. Já foi finalizado os ajustes nos componentes: ACBrBPe, ACBrCTe, ACBrNF3e, ACBrNFCom e ACBrNFe. Os fontes alterados bem como os Schemas e os programas exemplos dos 5 componentes mencionados acima já estão no SVN. Quero lembrar que ainda não é possível enviar o XML contendo os novos campos para a SEFAZ, uma vez que esta ainda não liberou o ambiente de homologação que esta previsto para 01/07/2025. Estamos trabalhando já no componente ACBrNFSeX, mas como dito anteriormente até a postagem desse tópico não foi publicado os Schemas. No que se refere a NFSe temos duas questões: 1. A NT publicada com as mudanças no layout referente a Reforma Tributária é no layout da NFS-e Padrão Nacional (não confundir com ABRASF). 2. Hoje o componente ACBrNFSeX atende 1848 cidades, algumas delas contrataram provedores que usam a versão 1 do layout da ABRASF, outras contrataram provedores que usam a versão 2 do layout da ABRASF e outras contrataram provedores que tem layout próprio. Não sabemos qual a atitude dos provedores que utilizam a versão 1 ou 2 do layout da ABRASF bem como os que tem o seu próprio layout no que se refere a Reforma Tributária. Eles vão alterar o layout que usam para adequar a Reforma ou vão abandonar o layout em uso e vão passar a usar o layout da NFS-e Padrão Nacional? Não temos a resposta para essa pergunta. Até a próxima pessoal.

Coordenação Técnica do ENCAT 04/07/2025 Conformidade Fácil - Validador RTC Encontra-se disponível no portal da SVRS a nova funcionalidade do Projeto Conformidade Fácil: o validador das notas técnicas da Reforma Tributária do Consumo. Nesta transação, qualquer empresa ou integradora de software poderá informar a parte do XML com os campos da tributação apresentados nas notas técnicas da RTC ou mesmo colar o XML completo de um documento fiscal eletrônico e validar se a informação está em conformidade com as regras de validação descritas nas notas técnicas. O componente de validação é o mesmo que é utilizado pelo ambiente de autorização da SEFAZ Virtual, e tem a capacidade de responder se o XML apresentado está correto em relação a qualquer uma das regras previstas nas NTs. A primeira versão atende aos documentos CTe, BPe, NF3e e NFCom, mas muito em breve estará contemplando NFe e NFCe. A etapa 3 prevê a criação de um gerador de XML da reforma tributária e deve ser implantada ainda no mês de Julho. Acesso a ferramenta: https://dfe-portal.svrs.rs.gov.br/Dfe/ValidadorRTC

Olá a todos, espero que estejam bem. Trabalho na Tron Informática e utilizamos diversas funcionalidades do ACBr e vez ou outra acabamos encontrando alguma coisa desatualizada ou ficamos com alguma implementação parada aguardando a implementação e isso as vezes geram alguns atrasos. Por esse motivo gostaria de saber qual o procedimento para que a Tron consiga contribuir com o projeto, fazendo novas implementações e atualizações quando necessário. Dando uma olhada no fórum percebi que algumas pessoas criam tópicos para essas contribuições. Seria esse o procedimento? Ou também é possível enviar direto para o SVN com algo similar a um Pull Request? Caso tenha essa possibilidade gostaria que me explicassem como fazer pois nunca usei o SVN para envios, apenas uso para baixar as atualizações. Desde já agradeço a atenção de todos.

O que é o QR Code? A tag do QR Code é um elemento presente no leiaute da Nota Fiscal de Consumidor Eletrônica – NFC-e, modelo 65. Ela é composta por uma URL específica e por informações que identificam a NFC-e. Seu conteúdo é utilizado para gerar a imagem do QR Code no DANFE NFC-e. Quando escaneado pelos consumidores, o código permite a conferência das informações da nota fiscal autorizada. O que é o QR Code 3.0 ? A criação da tag do QR Code deve seguir um formato pré-estabelecido no Manual de Orientação ao Contribuinte, disponibilizado pela Sefaz. A versão 3.0 é a versão mais recente desse formato, trazendo alterações em relação à versão 2.0, utilizada anteriormente. Por que a versão 3.0 do QR Code foi criada? A principal novidade desta versão se encontra no fato de ela não fazer uso do Código de Segurança do Contribuinte (CSC), portanto, a mesma traz diversas vantagens tanto para as empresas quanto para a Sefaz no que diz respeito à organização e gerenciamento dessa informação. Vantagens para as empresas: Elimina a necessidade de manutenção de CSC. Reduz a complexidade de gerenciar CSCs por filial. Elimina controle de manter somente 2 CSCs ativos por UF. Vantagens para a Sefaz: Elimina a complexidade de mantar página da web para geração de CSC. Elimina a necessidade de manter web service de sincronismo com a Sefaz Virtual para UFs participantes desse tipo de ambiente autorizador. Permite a adoção deste controle de segurança sobre a emissão do QR-Code para todas as UF, considerando que atualmente algumas UF não mantém o controle do CSC no seu Portal de atendimento ao Contribuinte. Quais melhorias ou diferenças em relação a versão 2.0? A principal mudança entre as versões se encontra no fato de que a versão 3.0 não vai mais fazer uso do CSC, então está informação não faz mais parte da composição do QR Code. O tamanho do QR Code também foi alterado com a versão 3.0 permitindo agora tamanho mínimo de 60 caracteres e tamanho máximo de até 1000 caracteres. Em comparação com a versão 2.0, a versão 3.0 é mais simples. QR Code 2.0 x QR Code 3.0 Versão 2.0 – parâmetros do QR Code na emissão on-line: Chave de acesso da NFCe Versão do QR Code Tipo de ambiente Id CSC Hash gerado pela concatenação dos parâmetros anteriores com o CSC aplicando SHA-1 e convertido para hex Versão 3.0 – parâmetros do QR Code na emissão on-line: Chave de acesso da NFCe Versão do QR Code. Tipo de ambiente. Versão 2.0 - parâmetros do QR Code na emissão off-line: Chave de acesso da NFCe Versão do QR Code Tipo de ambiente Dia da data de emissão Valor total da NFCe Digest Value correspondente ao Hexadecimal do SHA-1 do conteúdo do XML Id CSC Hash gerado pela concatenação dos parâmetros anteriores com o CSC aplicando SHA-1 e convertido para hex Versão 3.0 – parâmetros do QR Code na emissão off-line: Chave de acesso da NFCe Versão do QR Code Tipo de Ambiente Dia da data de emissão Valor total da NFCE Tipo de Destinatário(1=CNPJ|2=CPF|3=IdEstrangeiro Identificação do Destinatário(CNPJ,CPF ou IdEstrangeiro. Assinatura formada pela concatenação dos parâmetros anteriores aplicado SHA-1 e convertidos para base 64. Como implementar no ACBr? O próprio componente ACBrNFe se encarrega de montar a string do QR Code no arquivo XML, portanto, para utilizar a versão 3.0, basta alterar a propriedade: ACBrNFe.Configuracoes.Geral.VersaoQRCode := veqr300; Caso utilize ACBrMonitorPLUS é preciso definir a configuração em tela no caminho DFe > WebServices: Caso utiliza a ACBrLibNFe, será preciso alterar o valor na configuração da biblioteca definindo o valor correspondente: Qual UF já está usando a versão 3.0? A nota técnica 2025/001, que detalha o QR Code 3.0, estabelece a data máxima de até 02/06/2025 para implementação do mesmo no ambiente de homologação. No entanto, recebemos relatos de que, mesmo após esta data, algumas UFs ainda apresentam problemas para recepcionar NFCe geradas com o QR Code nesta versão. Até o momento, recebemos a informação de que a Sefaz de Minas Gerais e do Mato Grosso do Sul estão aceitando a versão 3.0. Quando entra em vigor a versão 3.0 do QR Code? Os prazos estabelecidos pela nota técnica 2025/001 são: Implantação Teste: Até 02/06/2025 Implantação Produção: Até 01/09/2025 Como reconhecer um XML com QR Code 3.0? O QR Code gerado na versão 3.0 não requer mais o uso do CData. Outra forma é procurar pelo parâmetro correspondente a versão do QR Code que tanto na 2.0 quanto na 3.0 ocupam a mesma posição. Exemplo de QR Code gerado na versão 2.0 em emissão normal: Exemplo de QR Code gerado na versão 3.0 em emissão normal: A versão 3.0 do QR Code deve ser usada somente em contingência? Não! A versão 3.0 pode e deve ser utilizada tanto na emissão normal quanto na emissão em contingência de maneira semelhante a sua antecessora. Com a chegada da versão 3.0 é o fim da versão 2.0? Não! A versão 2.0 ainda continua valendo sem data prevista para ser descontinuada. Quem deve usar a versão 3.0? Até o momento, é recomendado que a versão 3.0 seja utilizada por produtores rurais pessoa física, eliminando a necessidade de gerenciar CSCs para pessoa física por UF (exceto para o PR). Pessoa jurídica pode escolher entre a versão 2.0 ou a versão 3.0

O link acima saiu quebrado, mas a notícia é desse link: https://www.gov.br/esocial/pt-br/noticias/prorrogacao-da-atualizacao-de-certificado-do-esocial-para-um-novo-padrao-de-seguranca

Bom dia, Inclusão Instituição SB Cash Alterações no ACBrBoleto 1: ACBrBancoSBCash - inclusão de nova Unit 2: cobBancoSBCash 3: 482: Result := CobBancoSBCash; 4: CobBancoSBCash : fBancoClass := TACBrBancoSBCash.create(Self); ACBrBoleto.pas ACBrBancoSBCash.pas

Olá pessoal! Conferindo às 16h30 do dia 30/06/2025, a notícia publicada no portal do e-Social que originou a criação deste tópico foi removida acessando pelo link: E também não pode mais ser localizada a partir da página inicial de notícias do e-Social:

Olá pessoal! Ao acessar o Portal SPEDMG > NF3e, o seguinte aviso é exibido informando sobre a manutenção e indisponibilidade do ambiente de homologação da NF3e na Sefaz de Minas Gerais entre os dias 02 e 03 de Julho.

Correção no SVN.

Olá pessoal! Foi publicado no dia 18/06/2025 a versão 2.13 do Manual de Integração do Contribuinte GNRe. Esta versão altera os campos de CNPJ para adequação ao CNPJ alfanumérico previsto para Julho de 2026. Como a propriedade já é do tipo string no componente, modificações não serão necessárias. A versão mais recente do manual pode ser encontrada direto no Portal do GNRe e também em nossa biblioteca Tools

senão me falha a memoria. acho que uma vez consultei um fiscal do sefaz. e mesmo disse que se precisa imprimir algo diferente da DANFCe. deve se gerar um comprovante posterior e imprimir, mas que o layout da DANFCe é que segue o manual, portanto não deve e não pode ser feito do jeito que desejar e só pode existir dados que tem no XML do documento

Se fossemos resumir a resposta em uma palavra, ela seria "depende" ¹ ... Antes de tudo, vamos deixar algo claro: quando falamos de web services de NFSe, estamos falando em um contexto municipal. Assim, no primeiro caso, uma nota fiscal emitida para a cidade A, nunca vai ser encontrada na base de dados das notas fiscais emitidas para a cidade B. Por exemplo: se consultar na prefeitura de Uberaba uma nota emitida em Uberlândia, você não vai achar nada, mesmo que seja utilizado o mesmo provedor para as duas cidades. No segundo caso, eu quero consultar e baixar as notas de uma prefeitura em específico. Nesse caso, vai depender de o provedor que atende a este município em específico ter implementado as consultas de NFSe por serviço prestado e tomado. Para conferir se o provedor permite isso, você pode utilizar o método que devolve as informações do provedor (mais informações neste tópico). Vejam um exemplo de retorno do provedor Giss na versão 2.04 onde implementa as consultas: As informações mencionadas acima se referem as notas emitidas para os municípios usando os provedores. Terceiro caso, é a emissão de notas de serviço por prestadores que são MEI ou de prefeituras que aderiram ao padrão nacional por completo. Em ambos os casos a nota será emitida no padrão nacional e o mesmo implementa um método de DistribuicaoDFe semelhante a método de mesmo nome da NFe, permitindo obter os XMLs das notas ao consultar por CNPJ e NSU. Como uso isso no ACBr? Solução ACBr Demais Provedores¹ Padrão Nacional Componente nativo ACBrNFSeX.ConsultarNFSeServicoPrestadoPorNumero; ACBrNFSeX.ConsultarNFSeServicoPrestadoPorPeriodo; ACBrNFSeX.ConsultarNFSeServicoPrestadoPorTomador; ACBrNFSeX.ConsultarNFSeServicoPrestadoPorIntermediario; ACBrNFSeX.ConsultarDFe ACBrMonitorPLUS NFSe.ConsultarNFSeServicoPrestadoPorNumero NFSe.ConsultarNFSeServicoPrestadoPorTomador NFSe.ConsultarNFSeServicoPrestadoPorIntermediario NFSe.ConsultarNFSeServicoPrestadoPorPeriodo NFSe.ConsultarNFSeServicoTomadoPorNumero NFSe.ConsultarNFSeServicoTomadoPorPrestador NFSe.ConsultarNFSeServicoTomadoPorTomador NFSe.ConsultarNFSeServicoTomadoPorIntermediario NFSe.ConsultarNFSeServicoTomadoPorPeriodo NFSe.ConsultarDFeNFSePorNSU NFSe.ConsultarDFeNFSePorChave ACBrLibNFSe NFSE_ConsultarNFSeServicoPrestadoPorNumero NFSE_ConsultarNFSeServicoPrestadoPorPeriodo NFSE_ConsultarNFSeServicoPrestadoPorTomador NFSE_ConsultarNFSeServicoPrestadoPorIntermediario NFSE_ConsultarNFSeServicoTomadoPorNumero NFSE_ConsultarNFSeServicoTomadoPorPrestador NFSE_ConsultarNFSeServicoTomadoPorTomador NFSE_ConsultarNFSeServicoTomadoPorPeriodo NFSE_ConsultarNFSeServicoTomadoPorIntermediario NFSE_ConsultarDFe ¹ Demais provedores considerando que eles implementam a consulta, se tentar executar o comando e o provedor não implementa a consulta será devolvida a mensagem "Serviço não implementado para este provedor".

Bom dia, resolvido! @Renato Rubinho e @Alexandre de Paula Obrigado.

Olá pessoal! Informamos que o componente ACBrNFe foi compatibilizado com a versão 1.10 desta nota técnica na review 39718. Versões do ACBrMonitorPLUS e da ACBrLibNFe compiladas depois das 11/06/2025 deverão engloba as modificações.

Resumindo. Para o banco Inter preciso só disso: if Titulo.NossoNumeroCorrespondente <> '' then begin dm.Boleto.Configuracoes.WebService.Operacao := tpConsultaDetalhe; dm.Boleto.Enviar; if dm.Boleto.ListaRetornoWeb[0].HTTPResultCode = 200 then begin Titulo.QrCode.emv := dm.Boleto.ListaRetornoWeb[0].DadosRet.TituloRet.EMV; end; end; E funciona perfeitamente. "Para o Banco Inter" que o retorno é em: dm.Boleto.ListaRetornoWeb[0].Dados.Ret.TituloRet.EMV considerando um título apenas na lista

Não existe relação entre os CSTs atuais com o cClassTrib. Nos anexos da LC 214/2025 é possível verificar os NCMs que sofrem redução de alíquota e relacionar com o cClassTrib correto.

Boa Daniel! Cara, o trabalho de vocês é de outro planeta, o que vocês fazem é excepcional, parabéns!

Olá pessoal! Foi publicada no dia 06/06/2025 a versão 1.05 desta nota técnica. Esta nova versão traz a adição de um novo grupo de compras governamentais e também ajustes em regras de validação. Alterações Foi adicionado um novo grupo para compras governamentais no IBSCBS chamado gTribCompraGov. O mesmo é composto pelos seguintes campos: pAliqIBSUF: Alíquota IBS da UF utilizada vTribBSUF: Valor do tributo do IBS da UF que seria devido sem aplicação do Art. 473 da LC 214/2025; pAliqIBSMun: Alíquota IBS do município utilizado. vTribIBSMun: Valor do tributo do IBS do município que seria devido sem aplicação do Art. 473 da LC 214/2025; pAliqCBS: Alíquota do CBS utilizada. vTribCBS: Valor da CBS Adiciona observação de que a mensagem de rejeição relacionada ao IBSCBS deverá devolver o item que ocasionou a rejeição. Adiciona a seguinte exceção as regras de validação que validam a presença do grupo IBSCBS e seu respectivo CST: Se o CRT informado pelo emitente for 1 Simples Nacional ou 4 -MEI, o grupo gIBSCBS NÃO será exigido Adiciona regras de validação que verificam a presença ou a ausência do novo grupo gTribCompraGov e também a somatória do IBS e do CBS presentes no mesmo. Adiciona a seguinte exceção na regra que devolve cStat 223 e a mensagem "NFCom Local informada deve ser da mesma UF da NFCom": Datas Implantação Homologação: Até 28/07/2025 Implantação Produção: 06/10/2025 E como fica o ACBr? Como foi adicionado um novo grupo no leiaute, modificações no componente respectivo serão necessárias. Criada a #TK-7189 para adequação do componente. Leia a versão 1.05 desta nota técnica na íntegra AQUI.

Olá pessoal! Foi publicada no dia 06/06/2025 a versão 1.05 desta nota técnica. Esta nova versão traz a adição de um novo grupo de compras governamentais e também ajustes em regras de validação. Alterações Foi adicionado um novo grupo para compras governamentais no IBSCBS chamado gTribCompraGov. O mesmo é composto pelos seguintes campos: pAliqIBSUF: Alíquota IBS da UF utilizada vTribBSUF: Valor do tributo do IBS da UF que seria devido sem aplicação do Art. 473 da LC 214/2025; pAliqIBSMun: Alíquota IBS do município utilizado. vTribIBSMun: Valor do tributo do IBS do município que seria devido sem aplicação do Art. 473 da LC 214/2025; pAliqCBS: Alíquota do CBS utilizada. vTribCBS: Valor da CBS Adiciona a seguinte exceção as regras de validação que validam a presença do grupo IBSCBS e seu respectivo CST: Adiciona regras de validação que verificam a presença ou a ausência do novo grupo gTribCompraGov e também a somatória do IBS e do CBS presentes no mesmo. Datas Implantação Homologação: Até 28/07/2025 Implantação Produção: 06/10/2025 E como fica o ACBr? Como foi adicionado um novo grupo no leiaute, modificações no componente respectivo serão necessárias. Criada a #TK-7187 para adequação do componente. Leia a versão 1.05 desta nota técnica na íntegra AQUI.

Acabei de implementar os métodos Comuns de uso do ACBrLib.. que são os métodos de configuração, versão, nome e etc. Assim que eu finalizar implementação dos métodos de uso do Componente ACBrNFCom, devo anexar uma versão aqui para que você possa fazer um teste inicial, combinado ? Qual versão ACBrLib você utiliza ? x86, x64 ? stdcall, cdecl, Single Thread ou MultiThread ?

Olá pessoal! Esta rejeição foi introduzida pela Nota Técnica 2025/001 e sua regra de validação é como segue: Como descrito na regra e na rejeição, está mensagem é devolvida quando é feito o envio de forma assíncrona de um lote de NF-e contendo apenas uma nota em seu conteúdo. Portanto, para evitar esta rejeição, sua aplicação precisa fazer o envio de forma síncrona caso haja apenas uma NF-e no lote ou fazer o envio de forma assíncrona com um lote contendo no mínimo duas notas. Veja mais sobre os envios síncrono e assíncrono no tópico abaixo:

Olá pessoal! Se você não sabe do que se trata as classes baseadas em ACBrXMLDocument, o tópico abaixo tem mais detalhes: Mas em um resumo: São classes criadas de forma a utilizar as vantagens da LibXML para leitura e escrita dos arquivos XML. Elas são mais rápidas do que as classes baseadas na PCN. Elas foram criadas com o objetivo de substituir a PCN. Como podem ver no tópico indicado acima, desde antes de dezembro de 2024 essas novas classes já estão disponíveis e podem ser utilizadas pela comunidade através de opção no instalador. Agora, 6 meses depois, decidimos que a essas classes serão adotadas como padrão pelo ACBr, ou seja, ao invés de a opção vir desmarcada no instalador, ela vira selecionada por default. Por que estamos realizando esta mudança? Como é mencionado no tópico, consideramos que elas trazem vantagens em comparação com as classes da PCN. Depois de um período de 6 meses, com a comunidade já podendo utilizar elas e sem relatos recentes de problemas, consideramos que elas já estão maduras o suficiente para serem adotadas como padrão. Com o advento da Reforma Tributária, fica inviável manter a manutenção tanto nas classes PCN quanto nas classes ACBrXMLDocument, portanto, os novos campos relacionados a reforma foram adicionadas somente nas novas classes. Quais impactos essa mudança pode gerar? Como mencionado, essas novas classes precisam da LibXML para o correto funcionamento, portanto as dlls devem ser devidamente distribuídas junto ao executável ou estarem presentes no Path. Se você utiliza as units em sua aplicação, é provável que precise realizar a troca para evitar problemas de escopo. Por exemplo, substituir na seção uses da sua aplicação, onde tiver pcnNFeW por ACBrNFe.XmlWriter e onde tiver pcnNFeR por ACBrNFe.XmlReader.

Olá Pessoal, É com grande alegria que informo a todos que o componente ACBrNFe já esta em conformidade com a NT 2025/002 versão 1.01 referente a Reforma Tributária. Já se encontra no SVN os fontes, os Schemas e o programa exemplo em Delphi que exemplifica como alimentar os novos campos. Quero deixar bem claro que o ambiente de homologação só vai estar liberado em 01/07/2025 para recepcionar os XML com os novos campos referente a Reforma Tributária. Portanto nem adianta tentar enviar que o XML vai ser rejeitado.

Olá Pessoal, Foi publicado ontem (28/03/2025) Notas Técnicas especificas para cada modelo de Documento Fiscal Eletrônico referente a Reforma Tributária. Notas Técnicas publicadas para o BP-e, CT-e, NF3-e e NF-e/NFC-e, esta faltando a publicação da NT referente a NFCom. Em uma leitura rápida não ocorreu grandes alterações. Somente a NF-e/NFC-e que trazia um grupo referente a Compras Governamentais, este grupo agora esta presente nos demais DF-e. Outro ponto a se destacar é quanto aos prazos de liberação dos ambientes de homologação e produção. Ambiente de homologação que antes estava previsto para 01/09/2025 passou para 01/07/2025. E o ambiente de produção estava previsto para 31/10/225 passou para 01/10/2025. Com essa alteração de datas os desenvolvedores passaram a ter 3 meses em vez de 2 para adequar suas aplicações e fazerem os testes. No que se refere a NFS-e também foi publicado uma nova NT que traz algumas modificações no layout sendo que uma delas é a inclusão do grupo de Compras Governamentais. Infelizmente essa NT não traz datas de inicio do ambiente de homologação (produção restrita como eles chamam) e do ambiente de produção. A única informação que consta é que em janeiro/2026 as NFS-e devem já atender a reforma tributária, ou seja, já deve constar os novos grupos e campos. Com essas novas modificações nos layouts dos DF-e vamos ter que rever tudo o que foi feito e fazer as alterações necessárias. Pessoal, agora mais do que nunca devemos manter os fontes do ACBr atualizados e reinstalados se possível diariamente. Vamos fazer novos Papo Pro no Discord relatando as mudanças e em qual etapa estamos na adequação dos componentes. Não percam os Papo Pro eles são de extrema importância para que vocês fiquem informados.

Pessoal, A etapa 1 que visa implementar nas classes os novos grupos e campos, foi totalmente implementada em todos os componentes mencionados na postagem anterior. Vamos agora partir para a etapa 2.