Pesquisar na Comunidade

Olá pessoal! Foi publicada a Nota Técnica 2025/001 trazendo adequações da NF3e para a Reforma Tributária do Consumo. No âmbito do NF3e esta nota técnica substitui a NT mencionada no tópico abaixo: Vale reforçar que 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 de 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. Criação do grupo Compras Governamentais no grupo Ide No grupo de identificação do documento fiscal (ide), foi adicionado um grupo para identificar compra governamental (gCompraGov). O grupo possui 2 campos, um para indicar o tipo de compra governamental (tpCompraGov) e um para indicar o percentual de redução de alíquota em compra governamental (pRedutor). Inclusão de campos do IBS\CBS São adicionados campos para informar o IBS e o CBS além de totalizadores para os mesmos. Alteração no grupo do Sistema de Compensação da Energia Elétrica (SCEE) Adiciona os campos energia gerada (enerGer) e tipo de posto tarifário Energia gerada (tpPosTarGer). Preparação para o CNPJ alfanumérico A expressão regular que valida todos os campos de CNPJ passa a ser [A-Z0-9]{12}[0-9]{2} A expressão regular que valida a chave de acesso do BP-e que é composta dentre outras informações pelo CNPJ passa a ser [0-9]{6}[A-Z0-9]{12}[0-9]{26} Ampliação do cStat O código do status de retorno (cStat) passa a ter a seguinte regex [0-9]{3,4} aceitando na prática até 4 dígitos agora. Regras de validação Adiciona regras para validar as informações de compra governamental além dos novos campos de IBS, CBS e seus respectivos totalizadores. Datas Implantação Homologação: 07/2025 Implantação Produção: 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, mesmo assim a nota técnica será revista e quaisquer modificações necessárias serão efetuadas em tempo hábil para que possam ser disponibilizadas para vocês e possam testar. Leia esta Nota Técnica na íntegra AQUI. Os arquivos de schema já estão disponíveis e podem ser encontrados AQUI.

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! No dia 21/03/2025 foi publicada no Diário Oficial do Estado de São Paulo, a Portaria SRE 14, de 21 de Março de 2025. A mesma estabelece a obrigatoriedade da Nota Fiscal de Energia Elétrica (NF3e), modelo 66 e também da Nota Fiscal Fatura de Serviços de Comunicação (NFCom), modelo 62 no estado com os seguintes artigos: Vale ressaltar que o ACBr dispõe de componentes para emissão de ambos os documentos.

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á, bom dia! A pedido do Diego Folieni via discord, estou criando esse tópico. Estou usando o método "LoadFromString" para ler um XML de uma NF3e, porém está dando erro de conversão de datas. Pois não existe a tag no XML e ele tenta colocar "01/ / " no StrToDate. Segue em anexo o XML que estou usando para fazer a importação. Obrigado! xmlDfe-32240228152650000171660000053640211064015042.xml

Olá Boa Tarde, estou tentando emitir uma NF3e - Nota de Energia em Homologação, porem ao enviar os dados a rejeição 226 - Código da UF do Emitente diverge da UF autorizadora sempre me aparece, estou utilizando o software de exemplo e mesmo mudando a UF o mesmo erro me é apresentado, testei com SP tanto no cadastro do emitente quanto do WebService da Autorizadora pois o certificado que uso e de uma empresa de SP. Mesmo testando com outras UF e informando fixo no código a rejeição continua. Alguém saberia me informar o que pode ser o motivo? Desde já, muito obrigado Leonardo

Boa Tarde Pessoal, tudo bem? A Tag nSiteAutoriz não esta implementa, então quando gero o XML da NF3e, da erro de schema, informando a falta dessa tag. Acredito que seja necessário um ajuste no componente. Desde já, Muito Obrigado, Leonardo.

Boa tarde Pessoal, tudo bem? Estou tendo um problema com uma Tag cNF do componente, pois a mesma e alimentada a partir da função GerarCodigoDFe da unit ACBrDFeUtil, como essa mesma função é utilizada na NFe, não fiz alteração em código para não dar ruim, criei uma função própria para gerar esse numero. Mesmo com a função própria, no XML ela mostrava com 8 dígitos, onde o correto e receber 7, em uma outra parte do componente tive que fazer uma alteração para de fato ser criado essa Tag com o numero correto de dígitos função TNF3eW.GerarIde, vou deixar em anexo a Unit e a parte alterada da mesma. Percebi que essa Tag faz parte da Chave de acesso, então talvez alguma outra modificação seja necessária pois diminuiu um digito dela e talvez gere uma chave inválida. Desde já, Muito Obrigado, Leonardo pcnNF3eW.pas

Bom dia Pessoal, Tudo bem? A empresa em que trabalho tem um cliente que precisara emitir a NF3e a partir de setembro e eu fiquei com a responsabilidade de implementa-la. Ao gerar um XML para testes, ocorre um erro de Access Violation em uma parte do código do componente, mais especificamente dentro da procedure TNF3eW.GerarInfNF3e na unit pcnNF3eW, o erro acontece tanto na minha aplicação, quanto na de Exemplo da própria ACBr. A Tag correspondente urlQRCodePIX não foi alimentada e quando eu passo alguma informação pra ela, dai o erro acontece nesse momento da passagem de informação pra variável. Gostaria da Ajuda de vocês para poder resolver ou alguma dica de algo que eu possa ter deixado passar. Deixarei em anexo o print da linha em que se da o erro. Desde já, Muito Obrigado, Leonardo

Bom dia Pessoal, tudo bem? A Tag cClass, quando informo o código 0601000, ao gerar o XML a mesma fica com o valor 601000, dando erro de validação do schema, a maioria dos códigos da tabela de Classificação de Item da NF3e de Energia Elétrica começam por zero então pode ocorrer diversas vezes. Pra tentar solucionar, troquei o tipo da property referente, de Integer para String e o XML gerou corretamente, acredito que um ajuste no componente seja necessário. Desde já, Muito Obrigado, Leonardo.

Boa tarde. Gostaria de saber se por acaso existe algum componente para leitura de XML Nf3-e. https://www.confaz.fazenda.gov.br/legislacao/ajustes/2019/ajuste-sinief-01-19 https://dfe-portal.svrs.rs.gov.br/Nf3e#