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.

Olá pessoal! Foi publicado o AJUSTE SINIEF Nº 2, DE 11 DE ABRIL DE 2025 que aumenta o prazo em que o fisco deve guardar os documentos fiscais eletrônicos emitidos. Em outras palavras, agora o fisco deve guardar o XML da NF-e, CT-e, MDF-e, NFC-e, BP-e, NF3e, CTe-OS, GTV-e, DC-e, NFCom e todos os seus eventos vinculados por um período de 11 anos. O ajuste entra em vigor na data de sua publicação e produz efeitos a partir do primeiro dia do mês subsequente. Vale mencionar: O prazo de guarda desses documentos pelos contribuintes permanece inalterado conforme artigo 174 da Lei N° 5.172, de Outubro de 1996: Em outras palavras, a Sefaz precisa guardar os XMLs por 11 anos e o contribuinte precisa guardar o XML por 5 anos.

Olá pessoal! Foi publicado no dia 31/07/2024 a Nota Técnica 2024/001 abrangendo múltiplos DFes com o objetivo de adequá-los as modificações propostas pela Reforma Tributária. Introdução O PLP 68 estabelece que os estados, o distrito federal e os municípios devem padronizar seus sistemas autorizadores de documentos fiscais para permitir aos contribuintes que informem os dados relativos ao Imposto sobre Bens e Serviços (IBS), Contribuição sobre Bens e Serviços (CBS) e Imposto Seletivo (IS). Esta nota técnica, a princípio, trata em conjunto os seguintes documentos: Conhecimento de Transporte Eletrônico (modelo 57). Conhecimento de Transporte Eletrônico para Outros Serviços (modelo 67). Bilhete de Passagem Eletrônico (modelo 63). Nota Fiscal de Energia Elétrica (modelo 66). Nota Fiscal Fatura de Serviço de Comunicação Eletrônica (modelo 62). A versão final desta NT vai gerar NTs específicas para cada documento acima referido. A Nota Fiscal Eletrônica (modelo 55) junto da Nota Fiscal de Consumidor Eletrônica (modelo 65) vão ser tratadas em NT específica. Alterações Alteração do leiaute dos DFe Adiciona grupo para informação do IBS/CBS Adiciona no layout dos documentos mencionados o Grupo de Informações da Tributação IBS/CBS (IBSCBS) que fará parte do grupo imposto/imp, deverá ser adicionado em cada item nos documentos que apresentarem itens (NF3e/NFCom) ou diretamente no corpo do documento caso ele não possua itens (CTe/BPe). O IBSCBS é composto por um elemento para informação do Código da Situação Tributária do IBS/CBS (CST), um elemento para informação do Código da Classificação Tributária do IBS/CBS (cClassTrib) e um Grupo para as Informações Específicas do IBS/CBS (gIBSCBS), este último possuindo seus próprios elementos e subgrupos. Considerando apenas os elementos, o grupo IBSCBS adiciona um total de 48 novas informações a serem preenchidas no arquivo. O arquivo DFeTiposBasicos_v1.00.xsd adicionado ao pacote de schemas que compõe o DFe trás os referidos campos. Adiciona grupo para totalização do IBS/CBS Para a NF3e, NFCom e BPe TM também deverá ser adicionado no grupo total do respectivo documento um grupo para totalizar as informações do IBS/CBS (IBSCBSTot). Para CTe, CTe Simplificado, CTeOS e BPe não será criado. Adiciona campo para totalização do documento acrescida do IBS/CBS Na NF3e, NFCom e BPe TM adiciona no grupo total o campo vTotDFe que deverá receber o valor correspondente a (vNF/vTPrest + total do IBS + total da CBS). No CTe, CTe Simplificado, CTe OS e BPe a referida Tag será adicionada no grupo imp. Código Situação Tributária e Classificação da Tributação Será disponibilizado no portal dos respectivos documentos tabelas relacionando o CST x cClassTrib para o correto preenchimento das informações. Regras de Validação Esta nota técnica adiciona regras de validação que verificam dentre outras coisas se: Foi informado CST correto para o IBS/CBS Foi informado classificação tributária correta para o IBS/CBS. O grupo IBS/CBS foi preenchido quando não deveria. O grupo IBS/CBS não foi preenchido quando deveria. Os valores informados nos campos foram preenchidos corretamente. Os valores referentes a crédito presumido foram preenchidos nas situações em que são obrigatórios. Os valores referentes a desoneração foram preenchidos nas situações em que são obrigatórios. Os totalizadores correspondem a soma dos valores individuais. Datas Implantação Homologação: 01/09/2025 Implantação Produção: 31/10/2025 Vale ressaltar que como as discussões referentes a reforma tributária ainda estão em curso, a NT pode ser ajustada ao longo do processo. E como fica o ACBr? Serão necessários ajustes nos fontes do ACBr e novas compilações do Monitor e da Lib. Foi criada a #TK-5814 em nosso backlog para alteração dos fontes. Vale ressaltar que a NT é recente e existe um período expressivo até que seja liberada a homologação. Leia a NT na íntegra AQUI.

Olá pessoal! No dia 13/11/2024 foi publicada a versão 1.05 da Nota Técnica 2015/002 para o CT-e. Esta nota técnica trata sobre o web service de Distribuição de DF-e para o CT-e. A nova versão adiciona o CT-e Simplificado como um documento a ser devolvido pela distribuição, para o Tomador e também para Terceiros. Com esta nova versão, o CT-e, CTe-OS, GTV-e e agora o CT-e Simplificado são devolvidos para os participantes de acordo com o quadro abaixo: Datas As datas tanto do ambiente de homologação quanto do ambiente de produção estão como 21/10/2024, dando a entender que a NT já está em vigor em ambos os ambientes. Vale lembrar: A solução ACBr já implementa o processo de Distribuição DFe para o CT-e. Leia a versão 1.05 da Nota Técnica na íntegra AQUI.

Olá pessoal! Foi detectado a necessidade de uma correção na informação do ModeloDF para a Lib do CT-e. Atualmente na documentação consta da seguinte forma: No entanto, a Lib faz uso do enumerado nativo do componente e o mesmo possui a seguinte estrutura: TModeloCTe = (moCTe, moGTVe, moCTeOS); Portanto, a correta relação de conversão é: A informação foi corrigida na documentação e será atualizada em compilação posterior. Para quem utiliza as classes de alto nível do C#, o enumerado corrigido já foi disponibilizado no SVN e o pacote Core disponível no nuget foi atualizado.

Olá pessoal! No site da secretária do estado do Mato Grosso, consta uma NOTÍCIA informando que a Sefaz do Mato Grosso realizará no dia 10/08/2024 uma parada programada para atualização da versão do banco de dados utilizado. A manutenção está prevista para iniciar às 15h00 e ser concluída até às 22h00 do mesmo dia. Os ambientes autorizadores da NF-e, NFC-e e NF3-e já foram atualizados. A previsão é de que o ambiente autorizador do CT-e será afetado e durante este período a contingência SVC seja ativada. Para utilizar as soluções ACBr em contingência, siga as orientações deste tópico:

Boa Tarde Prezados(as) Alguém mais esta com este problema de emissão de cc-e de ct-e? Já verificamos o xml e me parece que esta tudo ok, vi em outros posts que geralmente é a sefaz que esta com problemas. Se alguém puder ajudar com alguma informação por gentileza serei grato. Rejeição: Carta de correção inválida (campo/grupo [Value cannot be null. Parameter name: input] informado não existe no schema do CT-e ou não existe no grupo informado), Que todos tenham um ótimo dia. 35210402426291000100570020000095151018403016_70401-cce.xml

Olá, sou novo na utilização do componente da acbr e tenho algumas duvidas em relação a NT 2021/001 CTe. Sobre a validação de duplicidade da chave natural, desativação da rejeição para numeração inutilizada e alterações no Schema XML. Essas alterações são tratadas no componente da acbr sem a necessidade de alterações no meu fonte?

Olá. Migrei o CT-e do 2010 para o Rio e depois de assinar, ao validar o CT-e me retorna a mensagem "CTe não encontrada no XML". segue o xml do CT-e gerado.cte.xml

Bom dia, tenho o seguinte inconveniente: CT-e Normal e CT-e Complementar do Normal, ambos com Evento Prestação de serviço em desacordo pelo tomador Contribuinte . Ao tentar emitir o CT-e Anulação do CT-e (Normal) o retorno é que por ter Complementar não pode ser feito o CT-e Anulação. Ao tentar emitir Anulação do CT-e Complementar o retorno indica que precisa ser Normal ou Substituto, ao tentar emitir Substituto o mesmo retorno. Já emiti CT Anulação e Substituto sem problemas de outros CT-e normais. Desde já agradeço a atenção. PS: não consegui adicionar o tópico no lugar correto.

Bom dia, Gostaria de uma orientação, de alguém que já passou pelo problema abaixo ou sabe como proceder Temos um cliente que emitiu um CT-e de forma incorreta, ele indicou que o tomador do frente era o Remetente, porém o correto seria o Destinatário, o problema é que perceberam o erro quando já não era mais possível cancelar este CT-e para assim emitir um novo com a correção. Portanto o Remetente emitiu o evento de "Prestação de Serviço em Desacordo" e agora pelo que entendi cabe a transportadora (nosso cliente) emitir um CT-e de Anulação e depois um de Substituição corrigindo a informação incorreta. Estou implementando pois até então não tínhamos a opção de "Anulação" em nosso sistema, fazendo testes em ambiente de homologação a emissão da Anulação ocorreu sem problemas, porém ao emitir o documento de Substituição estou recebendo a seguinte rejeição: "A indicação do tomador do CT-e de substituição deve ser igual a do CT-e substituído", de acordo com a mensagem da rejeição eu não posso alterar a indicação do tomador, mas como então posso fazer o documento de Substiuição? Nesse caso o cliente deve emitir somente a Anulação e um novo documento do tipo "Normal" com a indicação do tomador correta? Desde já, obrigado!

Bom dia. Gostaria de saber como vocês tratam o retorno de cancelamento de uma CT-e , pois acontece a seguinte situação as vezes ,quando envio um cancelamento e a sefaz ta lenta cancela normalmente a CT-e , mas eu não recebo o retorno, no meu sistema dependo do retorno para gravar algumas informações no banco de dados, isso acaba deixando inconsistente o meu relatório no final do mês. Att

Boa tarde, estou enviando o Comprovante de entrega eletrônico(CT-e) no ambiente de homologação para o estado de Minas Gerais, porém o retorno que tenho é 999 - Erro não catalogado. Segue em anexo os arquivos xml de envio e resposta 2-eve.xml 2-ped-eve.xml

Ao tentar cria o CT-e recebo esta mensagem 01/06/2019 19:21:13 - ERRO: Falha na validacao dos dados do Conhecimento: 1 1871 - Element '{http://www.portalfiscal.inf.br/cte}infDoc': Missing child element(s). Expected is one of ( {http://www.portalfiscal.inf.br/cte}infNF, {http://www.portalfiscal.inf.br/cte}infNFe, {http://www.portalfiscal.inf.br/cte}infOutros ). Estou tentando passar sem informações do grupo documentos mas não estou conseguindo gerar a TAG vazia usando o INI Como neste exemplo </infCarga> <infDoc/> <infModal versaoModal="3.00"> <rodo> <RNTRC>zzzz1509</RNTRC> </rodo> </infModal> Como devo enviar no Ini para criar a TAG <infoDoc> sem docs?

Bom dia, estamos tentando fazer o envio de um CT-e em contingencia devido a instabilidade do SEFAZ no estado de MG , mas está retornando um erro interno de que a sessão CTe_SVC-AN_P não foi encontrada no arquivo ABCrCTeServicos. O que pode estar acontecendo?

Prezados senhores, Preciso de um código fonte que lê um arquivo XML do Ct-e e recupere as informações ref. a cada campo para importar no banco de dados do nosso sistema. Trabalho com o Delphi 2007. Já procurei na internet e ainda não consegui achar nada.

Bom dia. Utilizando o ACBrMonitorPLUS-1.1.0.27 para emissão do CT-e 3.0 ocorre o erro de rejeição 239, já na consulta de Status e também quando tento emitir o CT-e. Anexo imagem da consulta ao Status de Serviço.

Tópico criado a pedido de @Juliana Tamizou para continuar o Tópico anterior Problema: Na impressão do DACTE de CT-e complementar, não é impresso a chave de acesso do CT-e complementado. Vi que o componente chega a carregar as informações (tpCTe= tcComplemento, cdsAnuladoComple.FieldByName('Chave').AsString:= CTE.infCteComp.chave), porém nada é impresso. Estou usando o arquivo DACTE_RETRATO.fr3 mais recente. Existe alguma propriedade que devo alterar para que essa informação seja impressa?

Boa tarde, há um erro no envio de CTe modal aquaviário que possua NF ou NFe nos dados de container. O fechamento desses grupos não estava sendo realizado, e isso fazia com que o XML gerado fosse inválido. Esse grupo está em infModal/aquav/detCon/infDoc. Por exemplo, o correto para esse grupo deveria ser: <infDoc> <infNFe> <chave>31180922010037000133550010000018051000120368</chave> </infNFe> </infDoc> Mas estava ficando: <infDoc> <infNFe> <chave>31180922010037000133550010000018051000120368</chave> </infDoc> Corrigi nos dois locais no arquivo anexado, se alguém puder dar uma olhada e implementar. pcteCTeW.pas

Olá pessoal, queria saber como faço para referenciar uma chave de CT-e nessa versão 3.0 na versão 2.0 ela era inserida na tag de identificação "ide" <ide> <refCTE> ... </refCTE> Como colocar o equivalente a essa tag na versão 3.0, alguém pode me ajudar?

Está ocorrendo o seguinte erro na impressão da inutilização da numeração do CT-e com o Fastreport. "Access violation at address ..." Para corrigir alterei a unit ACBrCTeDACTEFR e modifiquei o arquivo DACTE_INUTILIZACAO.fr3 utilizado para a impressão do mesmo. Segue em anexo os arquivos com as alterações: ACBrCTeDACTEFR.pas DACTE_INUTILIZACAO.fr3 xml de inutilização para teste: teste-ProcInutCTe.xml

Boa tarde Estou Com algumas dúvidas sobre o MDF-e. Já li bastante a respeito no site do Sefaz mas ainda estou com dúvidas. Esse documento é obrigatório quando? Tenho que fazer cada manifesto para cada CT-e? Todo CT-e que sai da empresa, tem que ter o Manifesto Também?

Na versão 3.00 do CT-e, o campo nDoc do grupo idDocAntPap foi alterado para tipo Caractere de tamanho 30, porém no ACBr continua como inteiro. Segue a alteração para string de 30 para avaliação. ACBrCTeConhecimentos.pas ACBrCTeDACTEFR.pas pcteCTe.pas pcteCTeR.pas pcteCTeW.pas

Olá, Necessito de um sistema com FONTES para emissão de CT-e e MDF-e que utiliza os componente do ACBR para integração e emissão dos relatorios em FastRepot, se possivel componente de acesso a dados Firedac. O Sistema tem que ser funcional e realizar as operações sem erros, deve contemplar desde o cadastro até a assinatura, envio, retorno, carta de correção, cancelamento, etc. Por favor, entrem em contato pelo e-mail [email protected] Obrigado Marcio Eduardo

Boa tarde pessoal. Estou tentando validar o CT-e em anexo pelo método: ACBrCTe1.Conhecimentos.LoadFromFile(...); ACBrCTe1.Conhecimentos.Validar; mas retorna o seguinte erro: Arquivo "Erro_v3.00.xsd" não encontrado. Acabei de atualizar os fontes (a pasta de Schemas também está atualizada), mas o erro persiste. Alguma ideia? Obrigado. 41180448740351000327570000013704871471254024.xml