Pesquisar na Comunidade

Olá pessoal! Foi publicada em 08/05/2025 a Nota Técnica Conjunta 2025/001 para tratar do CNPJ Alfanumérico modificado pela Instrução Normativa 2229 de 15 de outubro de 2024, afetando os ambientes autorizadores da NFe, NFCe, CTe, CTe OS, GTVe, MDFe, BPe, BPe TM, NF3e e NFCom. Nova lei de formação do número do CNPJ O tamanho do CNPJ permanece sendo 14, no entanto, agora as oito primeiras posições que identificam a raiz e as 4 posições seguintes que identificam a ordem do estabelecimento inscrito aceitaram caracteres alfanuméricos (letras e números). Os dois últimos dígitos verificadores permanecerão aceitando somente números. O cálculo dos dois últimos dígitos verificadores também foi alterado para se aceitar as novas possibilidades. Alterações necessárias nos Documentos Fiscais Eletrônicos Campos do tipo CNPJ Os arquivos de schema dos diversos DFes que utilizam o CNPJ já foram atualizados previamente alterando a expressão regular para aceitar letras maiúsculas nas primeiras 12 posições: [A-Z0-9]{12}[0-9]{2} Observação: Algumas letras não devem ser aceitas no CNPJ Alfa, como I, O, U, Q e F, essa exclusão faz parte das solicitações feitas pela equipe técnica do ENCAT para a Receita Federal do Brasil e precisa ser confirmada. Regras de Validação Não se aplicam modificações nas regras de validação relacionadas, considerando que as mesmas visam autenticar a veracidade dos 2 últimos dígitos verificadores do CNPJ. A partir da implementação desta NT, o contribuinte pode considerar que os ambientes autorizadores já estão adequados ao novo cálculo proposto para o DV. Nota aos Autorizadores: As rotinas de validação de CNPJ devem rejeitar CNPJ Alfanuméricos informados anteriores a data de implantação de cada ambiente (homologação e produção), mesmo que seja admitida a informação na validação de schema (já modificado). A rejeição aplicada nesse caso será a de falha no cálculo do Digito verificador. Chave de Acesso ao Documento Fiscal Eletrônico A expressão regular que valida a chave de acesso passa a suportar letras nas 12 primeiras posições da informação correspondente ao CNPJ que compõe a chave. Cálculo do DV da Chave de Acesso Assim como o cálculo do DV para o CNPJ foi alterado, também será necessário modificar o cálculo do DV da chave de acesso seguindo a mesma lógica proposta, a fim de suportar o alfanumérico. Regras de Validação da Chave de Acesso De forma semelhante as regras de validação relacionadas ao CNPJ, a regra de validação da chave de acesso vai validar o DV da chave e portanto o contribuinte pode considerar que o novo cálculo já vai estar sendo utilizado pelos sistemas autorizadores. Nota aos Autorizadores: As rotinas de validação de Chave de acesso devem rejeitar chaves contendo CNPJ Alfanuméricos informados anteriores a data de implantação de cada ambiente (homologação e produção), mesmo que seja admitida a informação na validação de schema (já modificado). A rejeição aplicada nesse caso será a de falha no CNPJ informado na chave de acesso. Padrão do Código de Barras dos Documentos Auxiliares O padrão utilizado atualmente é CODE-128C que suporta apenas números. A sugestão é a adoção de um modelo híbrido, usando o CODE-128C quando houver somente caracteres numéricos e o CODE-128A que aceita letras e números quando houver CNPJ alfanumérico. Datas A previsão de geração dos primeiros CNPJ Alfanuméricos está definida para julho de 2026. E como fica o ACBr? O componente ACBrValidador utilizado em funções para validar o CNPJ alfanumérico já está adequado para aceitar CNPJs Alfanuméricos. Foi criada a #TK-7034 para revisão dos componentes e possíveis adequações que possam vir a ser necessárias. Qualquer novidade será divulgada neste tópico. Leia a nota técnica na íntegra AQUI.

Prezados, Não estou conseguindo usar: ACBrValidador1.FormatarMascaraDinamica(). Lazarus 2.0.12 - FPC 3.2.0 devolve o seguinte erro: Error: identifier idents no member "FormatarMascaraDinamica".

Em testes com o ACBrValidador foi constatado que está passando o e-mail com esta formatação "marcelo @teste.br" não está testando se tem um espaço entre os caracteres da string. Baseado nisso fiz uma alteração na unit ACBrValidador.pas, segue a mesma para análise. linha alterada 831, adicionado espaço na lista de caracteres inválidos: ACBrValidador.pas

Prezados, Ao testar a validação do IE para todos os Estados, fazendo uso de um Gerador de IE, para os estados CE, PI e TO apresentou erro informando que o dígito estava incorreto.Ao acessar o site do Sintegra e efetuar a validação manualmente, foi confirmado que os IE estavam corretos. Segue abaixo, os IE's utilizados e o cálculo realizado. Ceara (http://www.sintegra.gov.br/Cad_Estados/cad_CE.html) IE : 93102768-3 Peso: 98765432 (9*9) + (8*3) + (7*1) +(6*0)+ (5*2) + (4*7) + (3*6) + (2*8) = 184 resto: 184 / 11 = 8 11-8 = 3 Piaui ( http://www.sintegra.gov.br/Cad_Estados/cad_PI.html ) IE : 12031409-6 Peso: 98765432 (9*1) + (8*2) + (7*0) +(6*3)+ (5*1) + (4*4) + (3*0) + (2*9) = 82 Resto: 82/11 = 5 11 - 5 = 6 Tocantins ( http://www.sintegra.gov.br/Cad_Estados/cad_TO.html ) IE :2803936475-2 Peso: 98--765432 (9*2) + (8*8) + (7*9) +(6*3)+ (5*6) + (4*4) + (3*7) + (2*5) = 240 Resto: 240/11 = 9 9 > 2, logo 11 - 9 = 2 Em anexo, segue a correção que foi aplicada para que seja validada. ACBrValidador.zip

Senhores, Estou tentando validar a Inscrição Estadual 9999999-40 (CNPJ 10.572.014/0001-33) do SEFAZ de PE, porém quando é feita a validação usando o método ValidarIE(no AcbrValidador.pas) ocorre um erro de validação do digito verificador.

Olá; Estou tentando utilizar o ACBrValidador mas de qualquer forma que eu faça sempre a validação se dá como Válida, mesmo com valores errados. No exemplo tbem acontece a mesma coisa.

Olá; Estou tentando utilizar o ACBrValidador mas de qualquer forma que eu faça sempre a validação se dá como Válida, mesmo com valores errados. No exemplo tbem acontece a mesma coisa.

Conforme solicitação do Sr. Henrique Leonardo @hleorj, estou criando um novo post referente a melhoria e alterações no método "FormarCEP" sobre post 1 e post 2, onde solicitei para alterar o método para preencher com zeros a direito ao invés de zeros a esquerda. Em meus clientes ocorre o seguinte: como a maioria das pequenas cidades possui apenas 1 CEP e nos casos em que os 3 últimos dígitos é "000", eles estavam acostumados a digitar por exemplo "89140" e o método FormatarCEP formatava para "89140-000". Quando migrei os fontes para o trunk2, este método passou a formatar os zeros a esquerda, ficando "00089-140". Em Dezembro de 2015 solicitei a alteração e o @Daniel Simoes alterou para formatar os zeros a direita, conforme post 1. Porém, essa semana atualizei os fontes e novamente foi alterado para formatar zeros a esquerda, por causa da impressão do DANF-e da NF-e que trata o campo CEP como integer e ocorria problemas com CEPs iniciados com zero, conforme post 2. Sugestão 1) Para tentar contribuir sem comprometer outras funcionalidades, sugeri a principio uma alteração na unit "ACBrValidador.pas", onde existem 2 métodos "FormtarCEP": o primeiro recebe um parâmetro string e o segundo um parâmetro integer. No método que recebe o parâmetro string, sugeri para formatar zeros a direita e no outro método que recebe o parâmetro como integer, formatar zeros a esquerda. Dessa forma não acontece o erro do post 2, porém, ao implementar um teste ( TDD ) que atenda a minha necessidade, a execução falhou no teste "FormatarMenosDeOitoDigitos". Os métodos "FormtarCEP" da unit "ACBrValidador.pas" ficariam da seguinte forma: function FormatarCEP(const AValue: String): String; Var S : String ; begin S := PadRight( OnlyNumber(AValue), 8, '0') ; { Prenche zeros a direita } Result := copy(S,1,5) + '-' + copy(S,6,3) ; end; function FormatarCEP(const AValue: Integer): String; Var S : String ; begin S := PadLeft( OnlyNumber(IntToStr(AValue)), 8, '0') ; { Prenche zeros a esquerda } Result := copy(S,1,5) + '-' + copy(S,6,3) ; end; Sugestão 2) Uma outra sugestão, seria criar um parâmetro no método "FormatarCEP" da unit "ACBrValidador.pas" para forçar o preenchimento dos zeros a direita, mas que por padrão, caso o parâmetro não seja informado, o valor seja False. A alteração ficaria da seguinte forma: function FormatarCEP(const AValue: String; PreencheZerosADireita: boolean = False): String; Var S : String ; begin if PreencheZerosADireita then S := PadRight( OnlyNumber(AValue), 8, '0') { Prenche zeros a direita } else S := PadLeft( OnlyNumber(AValue), 8, '0') ; { Prenche zeros a esquerda } Result := copy(S,1,5) + '-' + copy(S,6,3) ; end; e o teste na unit "ACBrValidadorTest.pas" ficaria assim: procedure TTestCaseACBrValidadorCEP.FormatarString; var ACep: String; begin ACep := '89140'; CheckEquals('89140-000', ACBrValidador.FormatarCEP(ACep, True)); end; Dessa forma, atenderia todos os testes (incluindo o teste que implementei). Segue em anexo os arquivos referente a segunda sugestão de alteração. ACBrValidador.pas acbrvalidadortest.pas