Painel de líderes

Olá Pessoal, Essa é uma boa pergunta. E a resposta é muito simples esta pronto e não esta pronto. Como assim? Até o momento temos a NT 2025/004 que traz as alterações no layout da NFS-e Padrão Nacional para a Reforma Tributária, mas não temos Manuais dos provedores que seguem a versão 1 do layout da ABRASF nem dos que seguem a versão 2 e nem dos provedores que tem layout próprio. O que temos pronto no ACBrNFSeX? Implementação dos novos grupos e campos visando a Reforma Tributária para o Padrão Nacional. Sendo assim através do programa exemplo é possível gerar o XML do DPS (Declaração de Prestação de Serviço), mas ao fazer isso vai ocorrer erro de validação. O motivo do erro é que os Schemas que temos não contempla os novos grupos e campos da Reforma Tributária. E o ambiente de homologação que a Receita Federal chama de Produção Restrita não foi alterado para aceitar os novos grupos e campos. Resumindo. Já esta no SVN as alterações no componente ACBrNFSeX para gerar o XML do DPS (Padrão Nacional) com os novos campos. Não vai ser possível validar e nem enviar para o ambiente de homologação. Assim que tivermos mais noticias sobre a Reforma Tributária na NFS-e, vamos divulgar.

Olá Pessoal, Com a Reforma Tributária temos novas opções de emissão de NF-e, vamos tentar entender como funciona essa tal de nota de Débito ou Crédito. Na Nota Técnica 2025/002 versão 1.20 no final da página 7 temos o item 4 que traz: 4. Finalidade Débito e Finalidade Crédito da NF-e Notas de Débito e Crédito são nomes de instrumentos utilizados mundialmente para documentar situações contábeis onde é necessário corrigir informações comerciais que foram registradas em um documento, que no Brasil é a Nota Fiscal. Esta Nota Técnica cria na NF-e modelo 55 as finalidades de emissões correspondentes. O sentido das palavras “débito” e “crédito” sempre se referem ao ponto de vista do emissor: • 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 emissão “Nota de Ajuste” e “Nota Complementar”, já existentes, são casos especiais de Nota de Débito; uma nota de entrada emitida para documentar, por exemplo, a devolução de mercadoria que havia sido vendida a um consumidor final, é um caso especial de Nota de Crédito. A regulamentação do IBS disporá sobre a utilização de notas de crédito e notas de débito para lançamentos de ajuste, com a finalidade de instrumentalizar a preparação da declaração assistida a ser oferecida para os contribuintes, de maneira automatizada, a partir de documentos fiscais eletrônicos, em cumprimento ao que preconiza a LC 214/2025. A menos que ocorra alteração na regulamentação do ICMS e do IPI, notas de crédito e notas de débito não poderão ser utilizadas para ajustes relativos a estes tributos. O campo finNFe agora passa a ter as opções: 5=Nota de crédito; 6=Nota de débito; Portanto se a minha intenção é emitir uma NF-e de Crédito o valor de finNFe tem que ser 5, por outro lado se a intenção é emitir uma NF-e de Débito o valor de finNFe tem que ser 6. Temos agora que especificar o tipo da nota de Débito ou de Crédito através dos novos campos tpNFDebito e tpNFCredito. Devemos ter em mente que uma nota só pode ser de Débito ou de Crédito jamais vai ser de Débito e Crédito. Valores aceitos pelo campo tpNFDebito: 01=Transferência de créditos para Cooperativas; 02=Anulação de Crédito por Saídas Imunes/Isentas; 03=Débitos de notas fiscais não processadas na apuração; 04=Multa e juros; 05=Transferência de crédito de sucessão; 06 = Pagamento antecipado 07 = Perda em estoque Valores aceitos pelo campo tpNFCredito: 01 = Multa e juros 02 = Apropriação de crédito presumido de IBS sobre o saldo devedor na ZFM (art. 450, § 1º, LC 214/25) 03 = Retorno (regra de validação: B25-80) Uma nota de Débito ou Crédito não podem conter informações de: ICMS (tag: ICMS), ISSQN (tag: ISSQN), IPI (tag: IPI), II (tag: II), PIS (tag: PIS), PIS ST (tag: PISST), COFINS (tag: COFINS), COFINS ST (tag: COFINSST), ICMS UF Destino (tag: ICMSUFDest) ou Imposto Devolvido (tag: impostoDevol). Uma NFC-e (modelo 65) não permite nota de Débito ou Crédito, esses dois tipos de notas estão restritas ao modelo 55 ou seja NF-e. (regra de validação: UB106-31) Temos um novo gruo chamado gTransfCred que só deve ser gerado se a de nota de Débito tiver o tpNFDebito for 01 ou 05. O grupo gTransfCred só deve ser gerado se o CST / cClassTrib informado o permitir. (regra de validação: VC02-10) Se tpNFDebito for 03 ou 04 devemos gerar o novo grupo DFeReferenciado. (regra de validação: 3BA02-70) Uma nota de crédito de multa/juros, tpNFCredito igual a 01 ou 03 tem que referenciar uma NF-e autorizada e não pode estar cancelada. (regra de validação: B25-30) Se tpNFCredito for 01 ou 03 devemos gerar o novo grupo DFeReferenciado. A nota de Débito ou Crédito não é simples, possui muitas regras de validação, vai ser natural levarmos uma rejeição logo na primeira nota, mas de posse da NT em mãos para buscar um entendimento sobre a rejeição e sanar o problema vai ser o caminho. Tudo é muito novo para nós desenvolvedores e para os contadores, o jeito vai ser dar as mãos e tentarmos buscar a melhor implementação. Não sou contador, sou desenvolver, mas busco sempre as respostas nos Manuais, Notas Técnicas e longas conversas com os contadores. Espero que esse texto possa ajudar um pouco com esses dois tipos de notas.

Coordenação Técnica do ENCAT 02/09/2025 Lançamento do Portal da Conformidade Fácil A partir de agora, o projeto Conformidade Fácil conta com uma área temática exclusiva no portal dos Documentos Fiscais Eletrônicos da SVRS. Neste espaço serão disponibilizados de forma mais direta os serviços e consultas, assim como, os materiais e novidades em relação a esta importante iniciativa do ENCAT, SVRS e PROCERGS. Link para acessar o Portal: Portal da Conformidade Fácil

Boa tarde @Farol TI, Já esta no SVN.

No meu caso conseguimos autorizar mudando o valor da tag "vIBS" para "0.00". Realmente o problema parece estar concentrado em algumas UF's (PR é uma delas).... Em SC está autorizando normalmente. Provável falta de atualização de Schema em alguns estados.

Bom dia gente... Também estou com este problema!!! Alguém pode dar uma luz?

ok, eu antes nao tinha visto nos fontes, mas baixei a versao mais atual, e ja tem as tags da reforma tributária, mas vamos ficar no aguardo.

Tanto o emitente quanto o destinatário estão com o cPais = 1058 né? Então, pega o notepad++ e faz uma pesquisa pela tag "cpais" na pasta de schemas, veja se tem alguma regra lá, se está faltando algum arquivo e etc.

Bom dia @Farol TI, Muito obrigado pela colaboração, já foi criado a tarefa ACBr 8037 para realizar a alteração.

Boa tarde @Marcelo Grando, Esta ocorrendo erro na leitura desse XML, pelo simples fato dele estar errado. Dentro do grupo obsCont e obsFisco o xCampo não é um elemento e sim um atributo. Veja como esta no manual: Veja como esta nos Schemas: Me desculpe mas não posso fazer a alteração que você esta sugerindo, pois vai contra o que esta no manual e nos schemas. Se esse XML é a sua aplicação que esta gerando, você fazer as devidas correções pois ele esta errado.

Boa tarde, Criada a tarefa ACBR-8034 para avaliação. Obrigado pela contribuição.

Bom dia @Sandro Felipe Adad, Já esta no SVN.

Prorrogado para 22 de Setembro de 2025;

Bom dia, pessoal, tudo bem? Estou implementando o DC-e, e já consegui fazer a emissão em homologação corretamente, inclusive com a assinatura. Agora estou fazendo a parte de registrar eventos, consegui montar o XML corretamente e assinar, mas recebo o seguinte retorno: <retEventoDCe xmlns="http://www.portalfiscal.inf.br/dce" versao="1.00"> <infEvento> <tpAmb>2</tpAmb> <verAplic>PR-v0.7.2</verAplic> <cOrgao>41</cOrgao> <cStat>298</cStat> <xMotivo>Assinatura difere do padrao do Sistema</xMotivo> </infEvento> </retEventoDCe> A documentação cita duas possibilidades pra esse erro, sendo: Mas não é esse o caso. Tanto a Reference URI está correta, quanto o atributo ID no elemento infEvento. Id está sendo formado corretamente no formato $"ID{EventCode}{DceAccessKey}{EventSequential:D3}". A assinatura está sendo feita com o mesmo algoritmo, chave, certificado e formato da autorização do DCe, que está funcionando. O arquivo também está passando corretamente nos schemas. Alguém passou por isso ou sabe como ajudar? Em anexo o XML completo formatado, apenas anonimizei alguns dados. Grato desde já! Abraços request-cancelamento.xml

Isso é o que eu chamo de passivo-agressivo

Olá Pessoal, Quanto mais eu rezo mais assombração aparece. Lá vamos nós ler a versão 1.20 da NT 2025/002 referente a Reforma Tributária da NF-e/NFC-e. Vamos a um resumo dela: Consta que somente a partir de 2027 as empresas do Simples Nacional e MEI ao emitir suas notas vão ter que informar as informações do IBS e CBS. Em uma nova NT vai ser detalhado essa obrigatoriedade para as empresas do SN e MEI. O campo tpNFCredito passa a ter um novo valor: 03 - Retorno. O grupo gIBSCBS passa a ter o campo vIBS que é o resultado de vIBSUF mais vIBSMun. O grupo gIBSCBSMono continha muitos campos, só que agora os campos foram distribuídos dentro dos grupos: gMonoPadrao, gMonoReten, gMonoRet e gMonoDif. Varias regras de validação foram alteradas. Já estamos trabalhando para deixar o componente ACBrNFe, a DLL ACBrLibNFe e o ACBrMonitor em conformidade com essa Nota Técnica.

Aqui funcionou para SP como FGTNunca em ambiente de produção. Obrigado.

me parece que MG é igua a SP coloque fgtsempre