Pesquisar na Comunidade

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

Seguindo a orientação recebida no Discord, estou criando este tópico para relatar um problema de layout que diagnosticamos, detalhar a solução de contorno encontrada e, principalmente, propor uma sugestão de melhoria para o componente ACBrNFeDANFEFR. 1. Descrição do Problema Enfrentamos um problema onde o texto no "Quadro de Identificação do Emitente" do DANFE era cortado na última linha (em anexo). O mais intrigante é que o problema ocorria apenas em máquinas de um cliente específico (tanto em Windows 7 quanto em Windows 10), mas não em nosso ambiente de desenvolvimento, mesmo utilizando o mesmo executável, mesmo template .fr3 e os mesmos dados exatos do emitente. 2. Diagnóstico e Causa Raiz Após um diagnóstico exaustivo e metódico, descartamos as seguintes causas comuns: DPI Scaling: Todas as máquinas envolvidas estavam configuradas em 100%. Drivers de Impressora: O problema persistia mesmo utilizando o "Microsoft XPS Document Writer" como impressora padrão. Inconsistência de Arquivos: o template .fr3 era idêntico em todos os ambientes. 3. Solução de Contorno Aplicada Para resolver o problema de forma imediata para o cliente, editamos diretamente o template NotaFiscalEletronica.fr3 no FastReport Designer. A solução foi alterar a propriedade LineSpacing do objeto TfrxMemoView do emitente, reduzindo seu valor de 2 para 1. Isso fez com que o texto coubesse perfeitamente no campo, resolvendo 100% o problema visual. Estou anexando a este tópico o arquivo .fr3 com esta modificação para análise. 4. Sugestão de Implementação de Nova Feature Embora a edição do template resolva o problema, ela cria a necessidade de manter um arquivo .fr3 customizado, o que pode complicar a manutenção e a distribuição do software a longo prazo, especialmente quando se lida com múltiplos clientes que podem ter necessidades pontuais. Minha sugestão é a implementação de uma nova funcionalidade no componente ACBrNFeDANFEFR que permita o acesso e a manipulação de propriedades de objetos do relatório FastReport em tempo de execução, diretamente via código Delphi. Algo do tipo: ACBrNFeDANFEFR 1.MemoEmitente.LineSpacing := 1; 5. Conforme pedido pelo @Victor H. Gonzales - Panda, algumas variáveis para reprodução: Razão Social (ACBrNFe1.NFe.Emit.xNome): 44 caracteres Linha do Endereço (...enderEmit.xLgr, nro): 30 caracteres E-mail (...enderEmit.email): 20 caracteres Informação Adicional (utilizando a propriedade ACBrNFe1.DANFE.Site): 44 caracteres NotaFiscalEletronica.rar

Olá pessoal! Foi publicada a Nota Técnica 2025/002 trazendo adequações da NF-e e da NFC-e para a Reforma Tributária do Consumo. No âmbito da NF-e e da NFC-e, esta nota técnica substitui a NT mencionada no tópico abaixo: É importante reforçar que: Em produção, no ano de 2025, as informações de tributação relativas ao IBS, CBS e IS serão opcionais e não serão validadas. As novas validações relacionadas a esses tributos serão aplicadas a partir de janeiro de 2026. Como as discussões envolvendo a implantação da Reforma Tributária ainda estão em curso, está NT pode sofrer ajustes ao longo do período. Alterações. Tipos Básicos da Tributação. Visando padronização entre os diversos documentos fiscais eletrônicos esta NT acrescenta o arquivo DFeTiposBasicos_v1.00.xsd ao conjunto padrão de arquivos de schema para todos os DFes. O arquivo define a estrutura com os novos campos adicionados. Código Situação Tributária e Código de Classificação da Tributação O grupo de informações do IBS, CBS e IS contém os campos CST e cClassTrib. No tópico abaixo é detalhado o informe técnico sobre a publicação da tabela que possui a relação desses códigos. Cada código cClassTrib corresponde a um dispositivo específico da Lei Complementar 214 / 2025, tornando objetiva a informação do contribuinte sobre como é feita a tributação do IBS/CBS por item. Finalidades débito e crédito da NF-e Uma nota de débito documenta uma situação na qual o emitente registra um aumento no imposto devido (consequentemente, uma redução no imposto devido pelo adquirente, que é o destinatário); Uma nota de crédito documenta uma situação na qual o emitente registra uma redução no imposto devido (consequentemente, um aumento no imposto devido pelo adquirente, que é o destinatário); As finalidades de "Nota de Ajuste" e "Nota Complementar" que já existem são casos especiais de "Nota de Débito". Já uma "Nota de Entada" emitida para documentar, por exemplo, a devolução de mercadoria que havia sido vendida para consumidor final é uma caso especial de "Nota de Crédito". Alterações no Layout O código do status da resposta (cStat) devolvido passa a ter tamanho 4. Adiciona no grupo de identificação da nota fiscal eletrônica (grupo Ide) ganha campos para informar o código do município do fato gerador do IBS/CBS, o tipo da nota de débito, o tipo da nota de crédito e um grupo para informar se é compra governamental. Adiciona um grupo com novos campos para receber as informações do IBS, CBS e IS por item. Adiciona um grupo para totalizar as informações do IBS, CBS e IS. Regras de validação Adiciona regras de validação que buscam validar os novos campos e suas informações, a citar alguns exemplos: cStat 1000 para validar se o fato gerador do IBS foi preenchido. cStat 1001 para validar se somente o IBS/CBS foram preenchidos quando finalidade for débito/crédito. cStat 1002 para validar se nota de compra governamental e informações devidamente preenchidas. ... Eventos Esta nota técnica cria os seguintes eventos para apuração do IBS e da CBS além de um evento de cancelamento genérico que permite cancelar qualquer um deles: 112110 - Informação de efetivo pagamento integral para liberar crédito presumido do adquirente.(Autor: Emitente) 211110 - Solicitação de Apropriação de crédito presumido.(Autor: Destinatário) 211120 - Destinação de item para consumo pessoal.(Autor: Emitente/Destinatário) 211124 - Perecimento, perda, roubo ou furto.(Autor: Destinarário) 211128 - Aceite de débito na apuração por emissão de nota de crédito.(Autor: Destinatário) 211130 - Imobilização de item.(Autor: Destinatário) 211140 - Solicitação de Apropriação de Crédito de Combustível.(Autor: Destinatário) 211150 - Solicitação de Apropriação de Crédito para bens e serviços que dependem de atividade do adquirente.(Autor: Destinatário) 212110 - Manifestação sobre Pedido de Transparência de Crédito de IBS em Operações de Sucessão.(Autor: Sucessora) 212120 - Manifestação sobre Pedido de Transparência de Crédito de CBS em Operações de Sucessão.(Autor: Sucessora) 412120 - Manifestação do Fisco sobre Pedido de Transferência de Crédito de IBS em Operações de Sucessão.(Autor: Fisco) 412130 - Manifestação do Fisco sobre Pedido de Transferência de Crédito de CBS em Operações de Sucessão.(Autor: Fisco 110001 - Cancelamento de Evento(Autor: Idem ao evento a ser cancelado). Datas Implantação Teste: 01/07/2025 Implantação Produção: 01/10/2025 E como fica o ACBr? Os componentes do ACBr já vem passando por um processo de adequação as mudanças propostas pela reforma, dito isso, essa nova versão traz algumas novas modificações, como o grupo para compras governamentais, tpNFDebito e tpNFCredito. Dito, será preciso revisar a nota e as alterações propostas com prováveis modificações sendo necessarias. Mas garantimos que as soluções do ACBr estarão de acordo com as mudanças propostas até as datas definidas, para que possam realizar seus devidos testes. Leia essa Nota Técnica na íntegra AQUI.

Olá pessoal! No dia 17/09/2024 foi publicada a Nota Técnica 2024/003 que traz alterações no layout e criação de regras de validação relacionadas ao trânsito de animais vivos, vegetais e florestais. Introdução Este documento visa permitir aos estados um acompanhamento mais preciso das operações relativas ao trânsito de produtos animais vivos, vegetais e florestais. Atendendo também solicitação do ENCCLA - Estratégia Nacional de Combate à Corrupção e à Lavagem de Dinheiro, encaminhada pelo Ofício nº 598/202 /CGAI/ DRCI/ SENAJUS/ MJ, do Ministério da Justiça para os estados em que não é utilizado o Documento de Origem Florestal (DOF). Alterações no arquivo XML da NF-e Foi adicionado no layout da NF-e um novo grupo chamado agropecuario para receber informações como o número do receituário da aplicação do defensivo até informações de guia florestal, adicionando ao menos 5 novos campos. Regras de Validação Junto do novo grupo, a nota técnica também traz novas regras de validação que verificam e validam os novos campos, validando: Se foi informado o número do receituário do defensivo agrícola. Se foi informada a guia de transito. Se foi informado documento de origem. Se a guia de transito informada é inválida. Se a guia de transito informada já foi utilizada. Datas Implantação teste: 02/10/2024 Implantação produção: 01/04/2025 E como fica o ACBr? Com a adição de novos campos no layout da NF-e, alterações no componente serão necessárias. Criada a #TK-5975 em nosso backlog para análise e implementação. Qualquer novidade será notificada neste tópico. Leia a Nota Técnica na integra 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:

Boa tarde pessoal, tudo certo? Ao atualizar o schemas de acordo com o que está na Sefaz para contemplar a tag modbcst com o valor "6 - Valor da Operação" (NT 2019.001 v1.30) estou tendo a rejeição conforme a imagem abaixo, antes de abrir este tópico procurei e encontrei um outro semelhante mas de 2017. Porém mesmo seguindo as instruções para alteração de uma linha em especifico não funcionou, há algo mais que eu possa estar fazendo pra corrigir essa questão?

Bom dia, Estou enfrentando um problema relacionado à configuração manual do fuso horário no componente ACBrNFe. Utilizo as propriedades ACBrNFe.Configuracoes.WebServices.TimeZoneConf.TimeZoneStr := '-04:00' e ACBrNFe.Configuracoes.WebServices.TimeZoneConf.ModoDeteccao := ACBrUtil.DateTime.tzManual para definir o fuso GMT-4 (Mato Grosso) manualmente. Também faço uma verificação antes de atribuir a data do evento (como no caso de uma CCe), onde, se o campo NR_FUSO da UF for maior que zero, aplico o modo manual com o fuso adequado. O problema é que essa configuração só surte efeito após a transmissão de uma NFe. Ou seja, se o sistema for iniciado e o usuário tentar diretamente registrar um evento (como uma carta de correção ou cancelamento), o fuso horário ainda não foi considerado corretamente, e a data do evento é gerada com o fuso padrão do sistema (por exemplo, -03:00). Com isso, recebo a rejeição: "Rejeição: A data do evento não pode ser menor que a data de emissão da NF-e." No meu caso específico, a nota foi emitida em 03/06/2025 às 15:45:23-04:00, mas como o componente ainda está assumindo -03:00, o evento acaba sendo enviado com, por exemplo, 15:52:36-03:00, o que faz com que a SEFAZ interprete que o evento ocorreu antes da emissão, gerando a rejeição. O maior problema é que nem sempre o usuário terá uma NFe para transmitir antes de emitir uma CCe, e muitas vezes os perfis dos usuários são distintos (quem transmite a nota não é quem gera a CCe ou cancela a NFe). ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Percebi que o problema parece estar na unit ACBrUtil.DateTime, especificamente na função GetUTC(UF: string; const dataHora: TDateTime): string. Essa função utiliza um case com base no valor de TimeZoneConf.ModoDeteccao para definir qual fuso utilizar. Se o modo estiver configurado como tzManual, ele deveria simplesmente retornar o valor de TimeZoneConf.TimeZoneStr. Obs: fiz o teste setando a configuração diretamente no componente e ocorre a mesma coisa, ou seja, o componente é alimentado corretemente somente depois de transmitir alguma nota. O meu ERP é utilizado por filiais que estão em GMT-3 e também em GMT-4, por isso precisa ser dinâmico esse timezone.

Olá pessoal! Foi publicado no dia 06/02/2025 correio eletrônico com a seguinte tabela com as datas previstas para a ativação de algumas regras de validação que vão validar a informação do cBenef informada nos documentos fiscais modelos 55 e 65. Regra de Validação Descrição da Regra de Validação Data de Ativação no ambiente de Produção N12-85 (NF-e) Se informado CST e não informado código de benefício fiscal: verificar se CST exige código de benefício fiscal (tag: cBenef), conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina 01/04/2025 N12-85 (NFC-e) Se informado CST e não informado código de benefício fiscal: verificar se CST exige código de benefício fiscal (tag: cBenef), conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina. 01/04/2025 N12-94 (NF-e e NFC-e) Se informado CST e informado código de benefício fiscal: verificar se código de benefício fiscal corresponde ao CST informado, conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina 28/04/2025 N12-98 (NF-e e NFC-e) Se informado código de benefício fiscal: verificar se o código de benefício fiscal existe e está vigente, conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina. 28/04/2025 N14a-20 (NF-e) Se CST de ICMS = 51 (diferimento) e informado tag:ICMS51/cBenefRBC (id:N14a): verificar se código de benefício fiscal de redução de BC (cBenefRBC) existe, está vigente e corresponde a um código de benefício de redução de base de cálculo (coluna CST 20 = SIM), conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina (NT 2019.001) 28/04/2025 I05h-10 (NF-e e NFC-e) Se informado código de crédito presumido (tag: cCredPresumido): verificar se código de crédito presumido existe, está vigente e corresponde a um código de crédito presumido, conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina (NT 2019.001). 28/04/2025 N12-86 (NF-e e NFC-e) Se informado CST e informado código de benefício fiscal: verificar se CST não possui código de benefício fiscal (tag: cBenef), conforme tabela de código de benefício fiscal por UF publicada no Portal da Secretaria de Fazenda de Santa Catarina. 01/09/2025 N14a-10 (NF-e) Se CST de ICMS = 51 (diferimento) e informado tag:ICMS51/pRedBC (id:N14) maior que zero, é obrigatório informar cBenefRBC (id:N14a) (NT 2019.001). 01/09/2025 Destacam-se nesta nova publicação: A postergação da ativação da regra de validação N12-85 para NF-e para o dia 01/04/2025 sendo ativada agora na mesma data para ambos os modelos. Aviso de que as regras de validação já foram ativadas no ambiente de homologação entre 04/11/2024 e 02/12/2024 para que os emissores já pudessem realizar os testes necessários. O não preenchimento dessa informação de acordo com as regras de validação a partir de sua ativação vai incorrer em rejeição do documento fiscal. Não será aceito o literal "SEM CBENEF". Tabela com os cBenefs a serem preenchidos pode ser encontrada em https://www.sef.sc.gov.br/saiba-mais/sped-fiscal O cBenef de crédito presumido possui campo próprio no leiaute (cCredPresumido) e deverá ser informado no mesmo a partir da ativação de regra de validação correspondente deixando assim de ser aceito no campo cBenef quando informado. Leia o Correio Eletrônico na íntegra AQUI.

Fala, galera boa do ACBr, então na impressão do DANFE paisagem em FastReport (DANFePaisagem.fr3) esta com uma questão de alinhamento na Unidade de Medida errado. Vou dizer que fico preocupado com os clientes que ficam reclamando disto, pois tem coisas muito mais importantes, em fim... Acontece que toda versão estou arrumando isto, se puderem arrumar no fonte original agradeço. Segue o print.

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! Ao conferir no painel Situação SVC-RS, é possível observar que a Sefaz do Paraná possui contingência agendada para o dia 18/05/2025, com previsão de inicio às 07h50 e encerramento às 20h30 do mesmo dia. Para utilizar as soluções ACBr em contingência durante esse período siga as orientações do tópico abaixo:

Olá pessoal! Conferindo no Portal da Nota Fiscal Eletrônica, é possível observar que a Sefaz de São Paulo está com a contingência agendada para o dia 18/05/2025, com previsão de início às 06h00 e encerramento às 14h00 do mesmo dia. Para utilizar as soluções ACBr em contingência durante esse período siga as orientações do tópico abaixo:

Olá, tudo bem? Vamos lá. Tenho uma aplicação que funcionava normalmente para o cancelamento da NF-e. A partir da semana passada, ela continua cancelando, porém não salva mais o arquivo e não traz as informações do nome do arquivo. Alguém pode me ajudar? FrmMenu.ACBrNFe1.NotasFiscais.Assinar; FrmMenu.ACBrNFe1.EnviarEvento(StrToInt(idLote)); MemoResp.Lines.Text := FrmMenu.ACBrNFe1.WebServices.EnvEvento.RetWS; memoRespWS.Lines.Text := FrmMenu.ACBrNFe1.WebServices.EnvEvento.RetornoWS; LoadXML(FrmMenu.ACBrNFe1.WebServices.EnvEvento.RetornoWS, WBResposta); DM.CNFE.Edit; DM.CNFECANCEL_TPAMB.AsString := TpAmbToStr(FrmMenu.ACBrNFe1.WebServices.EnvEvento.EventoRetorno.TpAmb); DM.CNFECANCEL_VERAPLIC.AsString := FrmMenu.ACBrNFe1.WebServices.EnvEvento.EventoRetorno.verAplic; DM.CNFECANCEL_CSTAT.AsInteger := FrmMenu.ACBrNFe1.WebServices.EnvEvento.EventoRetorno.cStat; DM.CNFECANCEL_XMOTIVO.AsString := FrmMenu.ACBrNFe1.WebServices.EnvEvento.EventoRetorno.xMotivo; DM.CNFECANCEL_CHNFE.AsString := FrmMenu.ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.chNFe; DM.CNFECANCEL_DHRECBTO.AsDateTime := FrmMenu.ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.dhRegEvento; DM.CNFECANCEL_PROTOCOLO.AsString := FrmMenu.ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.nProt; DM.CNFECANCEL_NLOTE.AsInteger := DM.CLOTIDLOTE.AsInteger; if FrmMenu.ACBrNFe1.WebServices.EnvEvento.cStat = DM.CNFECANCEL_CSTAT.AsInteger then begin CaminhoEvento := FrmMenu.ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.NomeArquivo; end else ShowMessage('Erro ao enviar o evento.'); if CaminhoEvento = '' then begin ShowMessage('Erro ao enviar o evento!'); Abort; end; Todos os campos do retorno funcionam, exceto este:CaminhoEvento := FrmMenu.ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.NomeArquivo; Desde já, agradeço!

Olá pessoal! Conferindo no painel Situação SVC-RS é possível observar que a Sefaz de Pernambuco ativou a contingência às 16h05 do dia 13/05/2025, com previsão de permanecer ativada até às 17h05 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: Um agradecimento ao membro de nossa comunidade @DAN ALVES por compartilhar a informação em nossa comunidade do Discord.

Olá pessoal! Conferindo no painel Situação SVC-RS é possível observar que a Sefaz do estado do Mato Grosso do Sul ativou a contingência às 14h40 do dia 13/05/2025, com previsão de permanecer ativada até as 09h00 do dia 14/05/2025. Para utilizar as soluções do ACBr em contingência durante este período siga as orientações do tópico abaixo: Um agradecimento ao membro de nossa comunidade @DAN ALVES por compartilhar a informação em nossa comunidade do Discord.

Olá pessoal! Ao conferir no painel Situação SVC-RS, é possível observar que a Sefaz do Paraná possui contingência agendada para o dia 10/05/2025, com previsão de inicio às 07h50 e encerramento às 19h30 do mesmo dia. Para utilizar as soluções ACBr em contingência durante este período siga as orientações do tópico abaixo: EDIT: Recebemos a informação de que a manutenção prevista na Sefaz do Paraná que iria ocorrer durante o período em que a contingência seria ativada não vai mais ocorrer. Isso, no entanto, não é impedimento para a a ativação da contingência conforme o agendamento.

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.