Pesquisar na Comunidade

Boa tarde, efetuando testes de envio de XML com as novas tags da reforma tributária, me deparei com o CST 410 - Imunidade e não incidência onde eu não devo encaminhar as tags do grupo <gIBSCBS>.no entanto, ainda preciso encaminhar as tags para informar que aquela operação é imune/não incidente. <CST>410</CST> <cClassTrib>410001</cClassTrib> Ocorre que o ACBr somente está levando CST e cClass quando vBC > 0. Entendo que isso está incorreto, pois em muitas situações não irá existir um vBC mesmo. Alguem mais se deparou com essa situação?

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.

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

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?

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! No dia 25/03/2025 foi publicada a versão 1.00 da NT2025/001. Alterações NFC-e: Leiaute QR-Code versão 3 O controle da autenticidade do conteúdo do QR-Code impresso no DANFE NFC-e para notas emitidas em contingência será feito por meio da assinatura de campos específicos do QR-Code e a inclusão do resultado da assinatura no mesmo. Neste novo modelo não será mais necessário controlar o Código de Segurança do Contribuinte(CSC), com previsão de eliminação dos mesmos(ainda sem data definida). NFC-e para Produtor Rural - Pessoa Física Em várias UFs é concecida uma Inscrição Estadual para os produtores rurais utilizarem com CPF. Isso gerava certa complexidade operacional para gerenciar os CSCs. Por causa disso, a orientação agora é que seja utilizado o novo leiaute QR-Code (versão 3) para o produtor rural pessoa física(exceto no PR). Para pessoa jurídica é permitida a escolha entre a versão 2 ou 3. Resposta Síncrona para Lote com somente 1 (uma) NF-e O envio de Lotes de NF-e que contenham apenas uma nota, agora deve ser feito de maneira síncrona. Controle do Atraso na Data de Emissão da NF-e A data de emissão da NF-e que anteriormente aceitava um atraso de 30 dias da data atual, agora aceitará um atraso de apenas 7. Regras de validação Desativa a regra de validação GAP03a-2 que devolvida cStat 776 e Rejeição: Solicitada resposta síncrona para UF que não disponibiliza este atendimento, substituindo a mesma pela GAP03a-3 que devolve cStat 452 e Rejeição: Solicitada resposta assíncrona para Lote com somente 1 (uma) NF-e. Altera a regra de validação que devolve cStat 228 e Rejeição Data de Emissão muito atrasada para que valide um prazo de 7 dias independente do tipo da emissão. Altera regras para validar o campo Identificador da IE do Destinatário (indIEDest). Adiciona regras de validação para verificar se foi informado dados de cobrança para pagamento a vista ou data de vencimento superior a dez anos. Torna obrigatórias algumas regras de validação antes facultativas que verificavam a presença e também validavam os dados detalhando o pagamento no grupo que recebe os dados do cartão (card) na NF-e/NFC-e. Adiciona regras de validação específicas para versão 3 do QR-Code. Datas Implantação Teste: Até 02/06/2025 Implantação Produção: Até 01/09/2025 E como fica o ACBr? Foi criada em nosso backlog a #TK-6814 para adequação dos fontes do ACBr para versão 3.0 do QR-Code. Qualquer novidade será divulgada neste tópico. Leia a Nota Técnica 2025/001 na íntegra AQUI. Leia a versão 6.0 das especificações técnicas do DANFE NFC-e QR Code 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! 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! 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:

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.

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! Este tópico visa responder as principais perguntas feitas pela audiência nas edições do Papo PRO ACBr correspondentes. Adeus à velha NFe? Prepare seu ACBr - Parte 01 Os layouts e schemas "Integrados" da versão atual + Layout reforma estão no site da Confaz? R: Os arquivos de schema podem ser encontrados no Portal da Nota Fiscal Eletrônica e também em nosso SVN. Para uso com as soluções ACBr é orientado fazer o uso dos schemas disponíveis em nosso SVN! As notas técnicas também podem ser encontras no portal ou em nossa biblioteca tools. Para quem está construindo NFe/NFCe agora no sistema, qual é a orientação? R: Como ainda estamos no período de transição, será necessário construir considerando a tributação existente e os novos propostos pela Reforma Tributária, é um consenso que a melhor forma de fazer isso é deixando o mais parametrizável possível, evitando ao máximo "chumbar" valores e alíquotas direto no código fonte. Outra dica é buscar sempre se manter informado lendo as notas técnicas relacionadas e acompanhando eventos, podcasts, lives e publicações de profissionais confiáveis da área. Por fim, lembrar que não há problema em pedir ajuda se necessário, existem profissionais que estão se debruçando sobre as mudanças com o objetivo de trazer as mesmas de uma forma mais didática para todos. Como vai ficar o CNPJ que consta na chave da nota fiscal com essa vinda do CNPJ Alfanumérico? R: Apesar de a regex para permitir CNPJ alfanumérico ter sido alterada em liberação de pacote de schemas relacionado a Reforma Tributária, é importante ressaltar que são processos diferentes sendo tratados em notas técnicas diferentes. A Reforma Tributária está sendo tratada na Nota Técnica 2025/002, já o CNPJ Alfanumérico está sendo tratado na Nota Técnica Conjunta 2025/001; A segunda estabelece mudança no regex do arquivo de schema para a chave de acesso e atualização nas regras de validação da chave para permitir o CNPJ Alfanumérico. Para o MDF-e, mesmo que ele não tenha nota técnica própria da reforma tributária, vai mudar a validação das chaves de acesso das NF-es e CT-es que são relacionados no mesmo? R: O regex dos schemas do MDF-e foram atualizados para permitir CNPJ Alfanumérico na Nota Técnica 2025/001 para o MDF-e e as regras de validação serão atualizadas conforme Nota Técnica Conjunta 2025/001, mas nenhuma delas tem relação com a Reforma Tributária. Para as Libs como fica a questão do XML? R: A biblioteca ACBrLibNFe já está adequada as modificações propostas pela nota técnica mais recente da reforma tributária para NF-e/NFC-e e a geração do XML com os novos campos pode ser testada seguindo modelo disponível na documentação. A versão do XML da NF-e será alterada para a Reforma Tributária? R: Não, a versão do XML tanto da NF-e quanto da NFC-e permanece sendo 4.00; Os novos campos da reforma precisam estar no XML em Produção no dia 01/10/2025? R: De acordo com a versão mais recente da nota técnica disponível até o momento da publicação deste tópico, as datas são: Inserção dos campos no XML: Implantação Teste: 01/07/2025 Implantação Produção: 01/10/2025 Aplicação das regras de validação: Implantação Teste: 01/07/2025 Implantação Produção: 01/2026 Quando vai ser de fato extinto o ICMS do XML, ou seja, quando vai começar a devolver rejeição se enviar no XML? R: De acordo com a Lei Complementar 214 o período de transição se estende até o ano de 2033, portanto os campos do ICMS deverão ser informados até lá. Existe possibilidade de voltarem atrás com a Reforma Tributária? R: A reforma tributária é um projeto extenso e amplamente discutido com legislação aprovada na câmara dos deputados e no senado e com regramento já sendo discutido e publicado pelos diversos entes fiscais e regulatórios, o que faz com que a possibilidade de adiamento ou mudanças muito grandes vá diminuindo cada vez mais. Não recomendamos contar com adiamento ou com qualquer tipo de "voltar atrás", quanto antes as aplicações forem adequadas melhor para as software house. A dupla do CST e cClassTrib vai ser string ou enumerado? R: Como ambos são informações com valores fixos definidos em tabela publicada, optou-se por criar um enumerado para cada uma das informações. A base de cálculo do IBS e do CBS vai ser a mesma? R: Sim, conforme pode ser observado na versão mais recente da nota técnica e também dos schemas, o campo da base de cálculo será o mesmo tanto para o IBS quanto para o CBS. Vai haver campos para esses novos impostos no DANFe? R: Até o momento da publicação deste tópico ainda não foi publicado normativa ou novo manual atualizando o leiaute dos impressos para adicionar os novos campos relacionados. Existe um programa exemplo próprio para a NF-e da Reforma Tributária ou é o mesmo? R: É o mesmo programa exemplo. Foi adicionado uma opção para permitir escolher se a rotina que alimenta uma NFe\NFCe com dados fictícios vai alimentar os dados relacionadas a reforma tributária ou não. Adeus à velha NFe? Prepare seu ACBr - Parte 02 O que acontece se ao chegar na data estipulada, não os campos não tiverem sido implementados? R: A partir do momento que elas forem aplicadas você receberá rejeições. A partir de que data os campos serão obrigatórios? R: A versão mais recente das notas técnicas estabelece em seu cronograma que os campos serão obrigatórios no ambiente de homologação a partir de 06/10/2025 e em produção a partir de 01/01/2026. Vide cronograma detalhado: Os schemas atualizados com os novos campos já estão disponíveis no SVN do ACBr? R: Sim, os arquivos de schema mais atuais já estão disponíveis em nosso SVN. Quais documentos serão impactados pela Reforma Tributária? R: Serão impactados a NFe, NFCe, NFSe, NFCom, NF3e, BPe, BPeTM, CTe, CTeOS e GTVe. Se a nota fiscal for de ajuste ou remessa, a mesma não poderá ser de débito ou crédito? R: Correto, pois o campo finalidade de emissão da NF-e ganhou os dois novos tipos nota de crédito e nota de débito e existem rejeições caso seja informado valor para tipo de nota de débito ou crédito com finalidade diferente de débito ou crédito. Existe algum parâmetro no componente ACBrNFe para habilitar a reforma tributária? R: Os programas de exemplo feitos em Delphi e Lazarus ganharam uma opção para definir ser gerado com as tags relacionadas a reforma tributária. Vale mencionar que isso possui apenas finalidade orientativa e selecionar esta opção apenas faz com que as propriedades correspondentes sejam alimentadas. Em suma, para que as tags sejam criadas no arquivo XML, basta alimentar as propriedades correspondentes. Se eu atualizar os schemas e o ACBr antes da data, isso vai impactar o envio em produção? R: Não, os campos relacionados a reforma tributária não serão gerados no arquivo XML a menos que suas propriedades correspondentes sejam preenchidas. Como ficam as tabelas de CST, CRT, NCM, CEST e afins? R: As tabelas de CST, CRT, NCM, CEST e afins permanecem acompanhando e sendo utilizadas para o preenchimento do documento. Mesmo o CST específico para o ICMS vai estar presente no leiaute do documento fiscal até 2032.

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: