Pesquisar na Comunidade
Showing results for tags 'Rejeicao'.
Encontrado 129 registros
-
Publicada nota técnica que adiciona regra de validação para o CIOT no MDF-e.
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá comunidade ! Foi publicada a Nota Técnica 2026/001 v1.00 para o MDF-e discorrendo sobre regra de validação para este documento. Alteração A nova NT não traz alterações no leiaute, ela apenas traz uma regra de validação que segue: Datas Implantação Homologação: 21/09/2026 Implantação Produção: 23/11/2026 Vale ressaltar que apesar das datas presentes na NT para a ativação da regra de validação, já existe Resolução que obriga o CIOT no MDF-e. E como fica o ACBr? Alterações no ACBr não são necessárias. Leia a nota técnica na íntegra AQUI.
-
Sefaz do Paraná devolvendo indevidamente a Rejeição 1034.
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá comunidade ! No dia 02/02/2026, por volta das 08h36, começamos a receber múltiplos relatos de membros da nossa comunidade com problemas para autorizar determinadas notas fiscais junto a Sefaz Paraná. Todos os relatos tem em comum o mesmo retorno com a seguinte rejeição: Como é possível observar, esta rejeição costuma ocorrer quando é utilizado um CST e um cClassTrib que tem redução de alíquota, mas o percentual utilizado é inválido. No entanto, tudo indica ser um problema de rejeição sendo devolvida indevidamente, pois temos relatos de notas como esta do exemplo abaixo sendo rejeitadas: <IBSCBS> <CST>200</CST> <cClassTrib>200003</cClassTrib> <gIBSCBS> <vBC>100.00</vBC> <gIBSUF> <pIBSUF>0.1000</pIBSUF> <gRed> <pRedAliq>100.0000</pRedAliq> <pAliqEfet>0.0000</pAliqEfet> </gRed> <vIBSUF>0.00</vIBSUF> </gIBSUF> <gIBSMun> <pIBSMun>0.0000</pIBSMun> <gRed> <pRedAliq>100.0000</pRedAliq> <pAliqEfet>0.0000</pAliqEfet> </gRed> <vIBSMun>0.00</vIBSMun> </gIBSMun> <vIBS>0.00</vIBS> <gCBS> <pCBS>0.9000</pCBS> <gRed> <pRedAliq>100.0000</pRedAliq> <pAliqEfet>0.0000</pAliqEfet> </gRed> <vCBS>0.00</vCBS> </gCBS> </gIBSCBS> </IBSCBS> Essa estrutura está correta de acordo com o Validador da Conformidade Fácil e o valor utilizado nos percentuais de redução também estão corretos de acordo com o CST x cClassTrib, conforme a Tabela de Classificação Tributária. Caso esteja enfrentando esta rejeição, o recomendado é que abra um Fale Conosco junto a Sefaz do Paraná.
-
Guia de Correção: Lista de Erros e Rejeições da NFS-e no Padrão Nacional
um tópico no fórum postou Diego Foliene NFS-e
E0039: O município emissor informado na DPS deve estar parametrizado para utilizar os emissores públicos nacionais, conforme parametrização do município no Sistema Nacional NFS-e. - Como resolver? E0116: A IM deve ser informada para o emitente prestador do serviço na DPS, conforme informações complementares registradas no CNC NFS-e do município emissor informado na DPS. - Como resolver? E0160: No mês de competência da NFS-e, a opção de situação perante o Simples Nacional, do prestador, informada na DPS não está de acordo com o cadastro Simples Nacional. - Como resolver? E0310: O código de tributação nacional informado não existe ou não está administrado pelo município de incidência do ISSQN na data de competência informada na DPS, conforme a lista de serviços nacional do Sistema Nacional NFS-e. - Como resolver? E0330: É obrigatório prestar informações de todos os campos relativos ao comércio exterior - Como resolver E0536 : Não é permitido o preenchimento de informações relativas à benefício municipal para o prestador de serviço ME/EPP que não tenha o regime de apuração de tributos nesta NFS-e fora do Simples Nacional - Como resolver E0690: A alíquota do Cofins deve ser informada quando a base de cálculo deste imposto for informada - Como resolver -
Rejeição 564: Total do Produto / Serviço difere do somatório dos itens - Como resolver?
um tópico no fórum postou Diego Foliene NF-e/NFC-e
Entendendo o problema A Nota Técnica 2025/002 é a publicação mais recente que menciona esta rejeição. Vejam que ela identifica 3 campos diferentes: W07: Equivale ao elemento vProd do grupo ICMSTot que compõe o total da nota. I11: Equivale ao elemento vProd do grupo prod que recebe as informações do item. I17b: Equivale ao elemento indTot do grupo prod que recebe as informações do item. Sabendo disso, podemos entender que ao devolver esta rejeição, o web service da Sefaz esta nos dizendo que no arquivo XML que enviamos o valor de vProd no total na nota não coincide com a somatória dos valores de vProd dos itens em que indTot tenha valor 1. Como resolver? Revise o arquivo XML fazendo a somatória de todos os vProd dos itens cujo valor de indTot esteja preenchido como 1. <prod> ... <vProd>100.00</vProd> <indTot>1</indTot> ... </prod> ... <ICMSTot> ... <vProd>100.00</vProd> ... </ICMSTot> Verifique se os valores coincidem. Quem utiliza componente nativo para Delphi ou Lazarus, pode colocar um break-point no local indicado no print e ao usar o método ACBrNFe.NotasFiscais.ValidarRegrasDeNegocio pode conferir no debug qual é o valor esperado e qual foi a soma:
-
Rejeição E0712: Para ME/EPP indTotTrib nunca poderá ser informado. - Como resolver?
um tópico no fórum postou Diego Foliene NFS-e
Entendendo o problema De acordo com a planilha ANEXO_I-SEFIN_ADN-DPS_NFSe-SNNFSe-v1.00-20251216 que contém o leiaute da NFS-e e as regras de validação aplicadas pela API do Padrão Nacional, está é a regra de validação que correspondente a esta rejeição: Campo Regra de Validação Código Rejeição indTotTrib Se a situação do emitente da DPS perante o Simples Nacional na data de competência informada for ME/EPP, o choice indTotTrib nunca poderá ser informado. E0712 Para ME/EPP indTotTrib nunca poderá ser informado. Ainda de acordo com o mesmo leiaute, a tag indTotTrib faz parte de um "elemento escolha" junto dos grupos vTotTrib, pTotTrib e pTotTribSN. Ou seja, o arquivo XML só vai poder ter o vTotTrib ou o pTotTrib ou o indTotTrib ou o pTotTribSN, mas nunca mais de um deles. Se você está recebendo essa rejeição, isso significa que seu arquivo está sendo enviado com o elemento indTotTrib, quando deveria ser com um dos outros 3. Como resolver? No momento de geração do XML, uma lógica é aplicada para definir qual é o grupo que vai ser gerado. Verifica se foram preenchidos os valores que compõe vTotTrib. Se forem maiores do que zero, gera o grupo vTotTrib; Se não foi gerado o grupo no passo anterior, verifica se foram preenchidos os valores que compõe pTotTrib. Se forem maiores do que zero, gera o grupo pTotTrib. Se não foi gerado o grupo no passo anterior, verifica se o valor de pTotTribSN é maior do que zero. Se for, gera o grupo pTotTribSN. Se não foi gerado o grupo no passo anterior, verifica se o valor de indTotTrib é zero, se for, gera o grupo indTotTrib. Considerando isso, é preciso preencher as informações de modo que o indTotTrib não seja gerado. Caso utilize ACBrNFSeX para Delphi e Lazarus Para gerar o vTotTrib preencha: NFSe.Servico.Valores.totTrib.vTotTribFed := NFSe.Servico.Valores.totTrib.vTotTribEst := NFSe.Servico.Valores.totTrib.vTotTribMun := NFSe.Servico.Valores.totTrib.indTotTrib := TindTotTrib.indSim; Para gerar o pTotTrib preencha: NFSe.Servico.Valores.totTrib.pTotTribFed := NFSe.Servico.Valores.totTrib.pTotTribEst := NFSe.Servico.Valores.totTrib.pTotTribMun := NFSe.Servico.Valores.totTrib.indTotTrib := TindTotTrib.indSim; Para gerar o pTotTribSN preencha: NFSe.Servico.Valores.totTrib.pTotTribSN := NFSe.Servico.Valores.totTrib.indTotTrib := TindTotTrib.indSim; Caso utilize ACBrMonitorPLUS ou ACBrLib Para gerar o vTotTrib preencha: [totTrib] vTotTribFed= vTotTribEst= vTotTribMun= indTotTrib=1 Para gerar o pTotTrib preencha: [totTrib] pTotTribFed= pTotTribEst= pTotTribMun= indTotTrib=1 Para gerar o pTotTribSN preencha: [totTrib] pTotTribSN= indTotTrib=1-
- 2
-
-
-
- e0712
- padraonacional
- (e 5 mais)
-
Rejeição 459: Cancelamento de evento inexistente - Como resolver?
um tópico no fórum postou Diego Foliene NF-e/NFC-e
Rejeição A reforma tributária adicionou 14 novos eventos que podem ser gerados vinculados a uma NFe pelos participantes emissor, destinatário e sucessora. Para que não fosse necessário criar 14 eventos de cancelamento correspondentes, foi criado um único evento de cancelamento genérico que pode ser usado para todos. Essa rejeição pode ser recebida ao tentar transmitir esse evento de cancelamento genérico. Solução A regra que devolve a rejeição procura na base de dados da sefaz um evento que tenha a chave de acesso, o tpEvento e o nSeqEvento correspondentes ao que está sendo enviado para o cancelamento. Portanto, se estiver recebendo essa rejeição, confirme se todos os elementos estão corretos. Por exemplo, se você não está enviando o nSeqEvento 4 no cancelamento quando o nSeqEvento do evento que está tentando cancelar é 3.
-
Melhoria na consulta do Cadastro Centralizado de Contribuintes!
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá comunidade ! O Cadastro Centralizado de Contribuintes (também conhecido como CCC) foi melhorado pela Sefaz do Rio Grande do Sul! Foi adicionado nas informações disponibilizadas pela consulta os documentos fiscais eletrônicos que o contribuinte está habilitado a emitir. Essa informação ajudará a evitar a rejeição "203 - Emissor não autorizado para emissão". Vale lembrar que para acessar esta funcionalidade é necessário realizar login com Gov.BR no portal. Também é importante reforçar que essa funcionalidade existe apenas no portal e a consulta via web service pelo método de consulta de cadastro não devolve essas informações.-
- 8
-
-
- consulta cadastro
- ccc
- (e 7 mais)
-
Algumas UFs estão devolvendo rejeições indevidas relacionadas a Reforma Tributária
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá, comunidade ! Temos recebidos múltiplos relatos em nosso servidor do Discord e também em nosso fórum de problemas ao emitir notas fiscais utilizando os campos da reforma tributária. Os relatos tem em comum a súbita devolução de rejeições relacionadas aos novos campos da reforma tributária para XMLs que eram aprovados anteriormente. Para citar dois exemplos: Mesmo informando <pIBSUF>0,10</pIBSUF> que é o valor a ser informado em 2025 e em 2026 conforme Lcp 214 e texto da própria regra de validação. Mesmo informando CST e cClassTrib válidos de acordo com a Tabela do Conformidade Fácil. Outro fato curioso foi a presença de alguns relatos mencionando que o problema ocorria apenas para NFC-e, com a emissão de NF-e continuando normalmente. Vale lembrar que está não é a primeira vez que isso ocorre: E apesar de tudo, é preciso haver compreensão e o bom senso de que as UFs também estão correndo para buscar a adequação de seus web services de emissão em tempo hábil. Por isso, caso esteja enfrentando problemas semelhantes, se constatar que o problema não se encontra no arquivo XML ao passar o mesmo pelo Validador da Sefaz do RS e pelo Validador da Conformidade Fácil. Abra uma Fale Conosco junto a Sefaz. Quanto mais pessoas relatando, mais rápido eles percebem que há algo de errado e tomam as devidas providências.-
- 10
-
-
-
- reformatributaria
- reforma tributaria
- (e 11 mais)
-
Olá comunidade ! No dia 06/10/2025, por volta das 08H19, começamos a receber relatos em nossa comunidade do Discord de membros recebendo rejeição ao tentar autorizar NFCe em alguns estados para o ambiente de homologação. Os relatos tem em comum a mesma rejeição: UFs cujo problema foi relatado até o momento: SP, MG, GO e PR. Esta rejeição está relacionada a Reforma Tributária sobre o Consumo, foi adicionada a partir da Nota Técnica 2025/002 e na versão 1.30, que é sua publicação mais recente, sua implementação foi postergada sem data definida no ambiente de homologação. Portanto, tudo indica que algumas Sefaz autorizadoras adiantaram a implementação da regra ou implementaram considerando cronograma de versão anterior da nota técnica. Os relatos confirmam ainda que os CRTs 1, 2 e 4 estão sendo tratados como CRT 3 exigindo as informações e também que até o momento desta publicação, apenas o modelo 65 está devolvendo a rejeição, com a NFe modelo 55 aceitando sem os campos. Caso esteja enfrentando problemas, como o relato foi no ambiente de homologação a sugestão é que abra um Fale Conosco junto a Sefaz relatando a questão. Também é importante lembrar que a rejeição pode ser sanada, caso os campos da reforma tributária sejam informados no arquivo XML.
-
Contexto Esta rejeição foi adicionada pela Nota Técnica 2025/001 e obriga o preenchimento das informações de pagamento no MDFe quando for realizado carga de lotação. O que é carga lotação? Carga lotação, as vezes chamada de carga fechada, é a operação em que o transporte das mercadorias de um único remetente ocupa toda a capacidade do veículo. Resolução Se você estiver recebendo esta rejeição ao tentar emitir o MDFe, você deve gerar o grupo InfPag que possui as informações de pagamento em seu arquivo XML. Caso utilize componente nativo para Delphi/Lazarus: uses ACBrMDFe.Classes; var lMDFe: TMDFe; lInfPag: TinfPagCollectionItem; lComp: TCompCollectionItem; lInfPrazo: TInfPrazoCollectionItem; begin lMDFe := ACBrMDFe.Manifestos.Add; //Preenchimento das demais informações do MDFe. lInfPag := lMDFe.rodo.infANTT.infPag.New; lInfPag.xNome := //String; lInfPag.idEstrangeiro := //String; lInfPag.CNPJCPF := //String; lInfPag.vContrato := //Double; lInfPag.indAltoDesemp := //TIndicador = (tiSim, tiNao); lInfPag.indPag := //TIndPag = (ipVista, ipPrazo); lInfPag.vAdiant := //Double; lInfPag.indAntecipaAdiant := //TIndicador = (tiSim, tiNao); lInfPag.tpAntecip := // TtpAntecip = (taNenhum, taNaoPermiteAntecipar, taPermiteAntecipar, taPermiteAnteciparComConfirmacao); lInfPag.InfBanc.codBanco := //String; lInfPag.InfBanc.codAgencia := //String; lInfPag.InfBanc.CNPJIPEF := //String; lInfPag.InfBanc.PIX := //String; lComp := lInfPag.Comp.New; lComp.tpComp := //TComp = (tcValePedagio, tcImpostos, tcDespesas, tcFrete, tcOutros); lComp.vComp := //Double; lComp.xComp := //String; lInfPrazo := lInfPag.infPrazo.New; lInfPrazo.nParcela := //Integer; lInfPrazo.dVenc := //TDateTime; lInfPrazo.vParcela := //Double; end; Caso utilize ACBrMonitorPLUS ou ACBrLib: [infPag001] CNPJCPF= xNome= idEstrangeiro= vContrato= indAltoDesemp= indPag= vAdiant= indAntecipaAdiant= tpAntecip= [Comp001001] tpComp= vComp= xComp= [infPrazo001001] nParcela= dVenc= vParcela= [infBanc001] CNPJIPEF= codBanco= codAgencia=
-
Olá pessoal! Ao acessar o portal SPED MG consta um aviso com a seguinte informação: A mesma deixa claro que no ambiente de homologação, será devolvido a mensagem de consumo indevido caso uma mesma rejeição de Duplicidade de NF-e com diferença na Chave de Acesso seja devolvida mais de 200 vezes em um período de uma hora. Por isso, é importante que verifiquem se sua aplicação possui um processo em loop que possa causar uma situação como esta. Por que isso é tão importante? Porque conforme observações nas regras de consumo indevido presentes na NT2018/002, a rejeição de consumo indevido faz com que seja necessário aguardar o período de uma hora para poder voltar a consumir o web service, no entanto, a critério da UF, após 50 bloqueios o contribuinte pode receber a rejeição 656 permanentemente até entrar em contato com a UF autorizadora para regularização.
-
Rejeição 1022: Grupo IBS\CBS não informado - Como resolver?
um tópico no fórum postou Diego Foliene NF-e/NFC-e
Esta rejeição ocorre quando as validações do web service da Sefaz não encontram o grupo gIBSCBS no arquivo XML nos casos em que ele é necessário. (ind_gIBSCBS = 1 na Tabela de Classificação Tributária ) Portanto, para sanar este problema é preciso preencher as informações relacionadas no arquivo XML: Para aqueles que usam o componente nativo para Delphi/Lazarus ACBrNFe uma maneira de fazer é: uses ACBrNFe.Classes; procedure RotinaQueAlimentaNFeNoComponente; var NotaF: NotaFiscal; Produto: TDetCollectionItem IBSCBS: TIBSCBS; begin NotaF := ACBrNFe.NotasFiscais.Add; //Preenchee as demais informações... Produto := NotaF.NFe.Det.New; //Adiciona o item. IBSCBS := Produto.Imposto.IBSCBS; IBSCBS.CST := TCSTIBSCBS.Valor; IBSCBS.cClassTrib := 'cClassTrib'; //Preencher as propriedades de: IBSCBS.gIBSCBS.XXXX end; Para quem utiliza a solução ACBrMonitorPLUS ou ACBrLibNFe deve preencher no arquivo INI que alimenta a nota as informações: [IBSCBS001] CST= cClassTrib= [gIBSCBS001] vBC= vIBS= [gIBSUF001] pIBSUF= vIBSUF= pDif= vDif= vDevTrib= pRedAliq= pAliqEfet= [gIBSMun001] pIBSMun= vIBSMun= pDif= vDif= vDevTrib= pRedAliq= pAliqEfet= [gCBS001] pCBS= vCBS= pDif= vDif= vDevTrib= pRedAliq= pAliqEfet= [gTribRegular001] CSTReg= cClassTribReg= pAliqEfetRegIBSUF= vTribRegIBSUF= pAliqEfetRegIBSMun= vTribRegIBSMun= pAliqEfetRegCBS= vTribRegCBS= [gIBSCredPres001] cCredPres= pCredPres= vCredPres= [gCBSCredPres001] cCredPres= pCredPres= vCredPres=
-
Estamos recebendo relatos de usuários com rejeição sobre os dados da operação de pagamento por cartão de credito (tPag = 3) /debito (tPag = 4) e Pix Dinamico (tPag = 17) Tabela de Rejeições NT 2025.001 v1.01 Se você NÃO TEM TEF integrado: Tipo de Integração (tag: tpIntegra) para “2 – Pagamento não integrado com o sistema de automação da empresa (Ex.: equipamento POS)”, assim, não será necessário informar os dados da transação com a Operadora de Cartões. Sobre o campo TpIntegra: ATENÇÃO: Caso a legislação estadual não possua uma legislação que obrigue a vinculação dos pagamentos Eletrônicos ao programa emissor. Dessa forma, há possibilidade em utilizar a opção do TpIntegra = 2 e não a necessidade de informar CNPJ da credenciadora. Lembrando que estados como RS, MT é obrigatório a integração de formas de pagamentos de forma automatizada, sem intervenção manual; Temos um curso sobre como informar os campos em RS e MT: https://acbr.nutror.com/curso/8d575bd8a7c0ac0fda312f9b12b1eb521e606446/integracao-dos-meios-de-pagamento-aos-documentos-fiscais-eletronicos Como fica o XML, sem TEF Integrado: <code>//Grupo de Pagamentos <pag> <tPag>04</tPag> <vPag>10.56</vPag> <card> //Tipo de Integração TEF NAO INTEGRADO 2 <tpIntegra>2</tpIntegra> </card> </pag></code> Como fica o XML com TEF Integrado (mais detalhes de campos veja o curso citado acima: <code>!-- Grupo de Pagamentos --> <pag> <tPag>04</tPag> <vPag>10.55</vPag> <card> <tpIntegra>1</tpIntegra> //CNPJ da Operador do Cartão <CNPJ>11222333000144</CNPJ> //Bandeira do Cartão <tBand>02</tBand> //Código de Autorização do pagamento em Cartão <cAut>123993</cAut> </card> </pag></code>
-
Atenção Rejeição 865, 866, 904 na validação da NFe/NFCe - Como Resolver
um tópico no fórum postou Daniel InfoCotidiano NF-e/NFC-e
Algumas das informações mais importantes, mas que nem todos dão a devida atenção ao emitir uma NFe/NFCe são os dado relacionados ao pagamento. No entanto se você não preencher corretamente, vai ter rejeições como estas abaixo: 865 - Rejeição Total dos Pagamentos menor que o total da nota: Soma do valor dos pagamentos (vPAG) está MENOR que o total da Nota vNF; Revise os valores para que ambos coincidam; 866 - Rejeição ausência de troco quando o valor dos pagamento informados maior que a nota Soma do valor dos pagamentos (vPAG) está MAIOR que o total da Nota vNF; Revise os valores para que ambos coincidam ou informe o valor do troco na propriedade vTROCO 904 - Rejeição: informado indevidamente campo valor pagamento confirme se o tPag é 90, caso positivo remova o valor informado vPAG
-
Está rejeição é detalhada na Nota Técnica 2025/001 Conforme é possível observar, esta rejeição é devolvida quando o XML que foi enviado possui apenas 1 ocorrência do grupo dup que tenha a data de vencimento com o mesmo valor da data de emissão. O web service interpreta isso como um pagamento à vista. Para evitar esta rejeição, você deve informar mais de uma ocorrência do grupo dup ou caso informe apenas uma, então a data de vencimento precisa ser diferente da data de emissão. uses ACBrNFe.Classes; //... var NotaF: NotaFiscal; Duplicata: TDupCollectionItem; begin NotaF := ACBrNFe.NotasFiscais.Add; NotaF.NFe.Ide.dEmi := Date; //Demais dados... Duplicata := NotaF.NFe.Cobr.Dup.New; Duplicata.nDup := '001'; Duplicata.dVenc := Date; Duplicata.vDup := ...; Duplicata := NotaF.NFe.Cobr.Dup.New; Duplicata.nDup := '002'; Duplicata.dVenc := IncDay(Now, 20); Duplicata.vDup := ...; end; OU uses ACBrNFe.Classes; //... var NotaF: NotaFiscal; Duplicata: TDupCollectionItem; begin NotaF := ACBrNFe.NotasFiscais.Add; NotaF.NFe.Ide.dEmi := Date; //Demais dados... Duplicata := NotaF.NFe.Cobr.Dup.New; Duplicata.nDup := '001'; Duplicata.dVenc := IncDay(Date, 10); Duplicata.vDup := ...; end; Caso utilize ACBrMonitorPLUS ou ACBrLib, a seção correspondente no arquivo INI é: [Duplicata001] nDup=001 dVenc=21/07/2025 vDup=... [Duplicata002] nDup=002 dVenc=10/08/2025 vDup=... //OU [Duplicata001] nDup=001 dVenc=10/08/2025 vDup=...
-
.thumb.jpg.9ac6eb62d16b8ad39acc52c0df686849.jpg)
O ambiente de homologação já está aceitando os novos campos da reforma tributária e também já está realizando as validações referentes a reforma e aos novos campos. Se você estiver recebendo a rejeição 1102: Rejeição: NF-e de devolução de mercadoria exige referenciamento do item da NF-e original no ambiente de homologação verifique as seguintes informações. Existe agora um grupo VC Referenciamento de item de outro Documento Fiscal Eletrônico - DF-e que traz a TAG DFeReferenciado. Neste grupo é preciso informar a chave de acesso e o numero do item do documento referenciado em alguns casos específicos. Um dos casos seria por exemplo notas de devolução onde a finNFe é igual a 4. Este grupo deve ser preenchido e assim não será apresentada a rejeição, porém é importante lembrar que no momento isso é válido APENAS para o ambiente de homologação. No ambiente de produção essas regras devem entrar em vigor apenas em Outubro. Atenção!!! Através dessa informação da NT 2025_002 v1.10 entendemos que as validações seriam aplicadas apenas se os campos fossem preenchidos. Porém tivemos relatos na comunidade de que e casos que as informações do XML foram enviadas sem os novos campos da Reforma Tributária e as regras de validação foram aplicadas. Neste caso você tem algumas alternativas: 1 - No ambiente de homologação já use sempre o layout com os dados e novos campos da Reforma Tributária. 2-Teste na produçao (eu não disse isso!!!) - O ambiente de produção não tem as novas regras de validação ativas. Então o que vale aqui é o layout atual do XML e tambéms as regras de validação atuais. 3- Fale com a SEFAZ! Avise a SEFAZ pelos seus canais oficiais se encontrar alguma inconsistência. Lembre que eles estão realizando a implementação e é importante ter um feedback dos desenvolvedores para que eles entendam que tudo está funcionando. (ou não!), afinal de contas se o seu cliente não te avisa que está com problema como você pode ajudá-lo? Links para te ajudar: Aqui tem tudo junto e misturado da Reforma Tributária. Você vai encontrar a documentação links e podcasts sobre o assunto: Portal Nacional da SEFAZ, aqui você tem o canal de atendimento e as ultimas publicações de notas tecnicas! https://www.nfe.fazenda.gov.br/portal/principal.aspx
-
- 3
-
-
- rejeição
- reforma tributaria
- (e 2 mais)
-
Olá pessoal! Conforme aviso no Portal SPEDMG > NFCom, a sefaz de Minas Gerais vai ativar a regra de validação que devolve a rejeição de consumo indevido no ambiente de produção da NFCom em 07/07/2025. Vale mencionar que o Manual de Orientação ao Contribuinte prevê a regra de validação e sua respectiva rejeição em casos que a Sefaz pode considerar como mal uso do web service.
-
- 1
-
-
- consumo indevido
- 678
- (e 6 mais)
-
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á, estou emitindo MDFe, e retorna o seguinte erro "699: Rejeição: Dados do seguro de carga incompletos para o modal rodoviario", porém todos os campos da seguradora estão valorizados, segue o xml para analise. 41250553034459000172580010000000171088569094-mdfe.xml
-
Olá pessoal! Ao acessar a página da Nota Fiscal de Fatura de Comunicação Eletrônica da Sefaz de Minas Gerais o seguinte aviso é exibido: (A notícia sobre a prorrogação da NFCom pode ser lida AQUI) Vale mencionar que o Manual de Orientação ao Contribuinte prevê a regra de validação e sua respectiva rejeição em casos que a Sefaz pode considerar como mal uso do web service:
-
- 2
-
-
- consumo indevido
- 678
- (e 6 mais)
-
Sefaz de São Paulo devolvendo a rejeição 552.
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá pessoal! No dia 31/03/2025, por volta das 13h55 começamos a receber alguns relatos em nossa comunidade de membros recebendo rejeição da Sefaz de São Paulo ao tentar emitir uma NF-e com cupom fiscal referenciado. Todos os relatos tem em comum receberem a mesma rejeição: Também é comum nos relatos que o cupom fiscal referenciado já se encontra autorizado junto a Sefaz e também o fato de que ao passar por validadores como o Visualizador de Mensagens do Projeto NF-e disponibilizado pela Sefaz do Rio Grande do Sul, nenhum erro é apontado. Esta é a regra de validação correspondente a esta rejeição: Vejam que a validação verifica se o CNPJ/CPF da chave de acesso está zerado ou com dígito verificador inválido. No entanto, isso não deveria ser um problema visto que as chaves vinculadas são de documentos já autorizados. Em casos assim, é muito importante que se abra um Fale Conosco junto a Sefaz para reportar o problema. Quanto mais relatos, mais cedo a Sefaz percebe que existe algo de errado. EDIT: Ainda no dia 01/04/2025, por volta das 12h40, começamos a receber relatos em nosso servidor do Discord de que o problema relatado neste tópico normalizou e as notas que antes estavam sendo rejeitadas agora estão sendo autorizadas. -
Sefaz da Bahia devolvendo a rejeição 204 indevidamente.
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá pessoal! No dia 25/02/2025, por volta das 15h40 começamos a receber em nosso servidor do Discord múltiplos relatos de membros de nossa comunidade com problemas para transmitir notas fiscais para a Sefaz da Bahia. Todos os relatos tinham em comum estarem recebendo a mesma rejeição: Como a rejeição não informa que há diferença na chave de acesso, subentende-se que a mesma nota fiscal que está tentando ser transmitida já existe na base de dados da Sefaz com a mesma chave de acesso. No entanto, os mesmos relatos também afirma que ao tentar consultar a referida chave é devolvida rejeição apontando que a nota fiscal não existe na base de dados da sefaz. No dia 26/02/2025, por volta das 09h17, o membro de nossa comunidade @wendelswl compartilhou no canal #sefaz a resposta que recebeu em chamado aberto junto ao Fale Conosco confirmando que o problema de fato é do lado da Sefaz:
-
Rejeição 974: CNPJ do responsável técnico diverge do cadastrado - Como resolver?
um tópico no fórum postou Diego Foliene NF-e/NFC-e
Primeiro um breve resumo sobre o Responsável Técnico. O grupo com os campos para preencher as informações do responsável técnico foram acrescentados no leiaute da NF-e\NFC-e na Nota Técnica 2018/005. Esses campos tem a finalidade de identificar para o fisco, quem é a empresa desenvolvedora ou a empresa responsável tecnicamente pelo sistema de emissão de NF-e\NFC-e. O grupo com todas as suas tags fica assim: <infRespTec> <CNPJ>...</CNPJ> <xContato>...</xContato> <email>...</email> <fone>...</fone> <idCSRT>...</idCSRT> <hashCSRT>...</hashCSRT> </infRespTec> Entendendo a rejeição. A mensagem da rejeição e sua regra de validação retiradas na integra da versão mais recente da NT até então é a que segue: Como é possível observar, infelizmente não há muito o que fazer. Se você está recebendo está rejeição, a validação do web service entende que o valor que foi informado na tag <CNPJ> está divergindo do que foi informado no cadastro junto a Sefaz regional. Considerando isso, sempre é válido revisar se: Não há espaçamento em branco no começo ou no fim da string dentro da tag. Não foi preenchido passando pontuação no CNPJ ao invés de somente números. Conferi tudo isso, minhas informações estão corretas e mesmo assim recebo rejeição... O membro de nossa comunidade @Daniel Weber compartilhou conosco uma situação em que estava recebendo esta rejeição mesmo as informações estando corretas. O caso era que o cliente tinha autorização de uso com o software dele, mas também com o emissor gratuito da Sefaz. Portanto, se as informações estiverem corretas e mesmo assim estiver recebendo esta rejeição, verifique se o cliente ao qual você está tentando realizar a emissão da nota não possui vínculo\autorização de uso para outro CNPJ de responsável técnico além do seu. Para mais informações, veja o tópico: Trazendo mais informações sobre essa situação, o membro de nossa comunidade @Cleberson Publitech compartilhou no canal #sefaz em nossa comunidade do Discord essa resposta que recebeu ao abrir um Fale Conosco junto a Sefaz PR para questionamento.
-
- 4
-
-
- responsavel tecnico
- csrt
- (e 6 mais)
-
Sefaz de São Paulo passando por problemas na emissão de NF-e.
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá pessoal! No dia 21/01/2025, por volta das 08h09, começamos a receber relatos no canal #sefaz em nossa comunidade do Discord de membros com problemas para emissão de NF-e junto a Sefaz de São Paulo. Todos os relatos tem em comum a Sefaz estar devolvendo a rejeição: Mesmo a informação estando correta de acordo com consultas disponíveis como o Sintegra. Conferindo no DownDetector, é possível observar que o volume de relatos de problema aumentou exponencialmente durante o mesmo período: Não á até o momento da publicação deste tópico aviso sobre contingência publicado no Portal da Nota Fiscal Eletrônica.
-
Rejeição 616: Nenhum grupo de documentos foi informado(CTe, CT, NFe, MDFe) - Como resolver?
um tópico no fórum postou Diego Foliene MDF-e
Entendendo o problema. O Manifesto Eletrônico de Documentos Fiscais (MDF-e), conforme seu leiaute, permite que sejam referenciados documentos originários. Estes documentos podem ser CT-es, NF-es ou outros MDF-es. Esta é a regra de validação corresponde a esta rejeição de acordo com o MOC Anexo I - Leiaute e as Regras de Validação: Conforme é possível observar, se você está recebendo está rejeição significa que essas informações não foram encontradas no arquivo XML que foi enviado ao web service. Como resolver? Se você utiliza o componente nativo para Delphi/Lazarus, precisa referenciar o documento conforme exemplo: var LManifesto: TManifesto; LInfMunDescarga: TinfMunDescargaCollectionItem; LInfCTe: TinfCTeCollectionItem; LInfCT: TinfCTCollectionItem; LinfNFe: TinfNFeCollectionItem; LInfMDFeTransp: TinfMDFeTranspCollectionItem; LInfUnidTransp: TinfUnidTranspCollectionItem; Lperi: TPeriCollectionItem; begin LManifesto := ACBrMDFe1.Manifestos.Add; LInfMunDescarga := LManifesto.MDFe.infDoc.infMunDescarga.New; //=============>CT-e<============================= LInfCTe := LInfMunDescarga.infCTe.New; LInfCTe.chCTe := ''; LInfCTe.SegCodBarra := ''; LInfCTe.indReentrega := ''; LInfUnidTransp := LInfCTe.infUnidTransp.New; LinfUnidTransp.tpUnidTransp := utOutros; LinfUnidTransp.idUnidTransp := ''; with LinfUnidTransp.lacUnidTransp.New do nLacre := ''; with LinfUnidTransp.infUnidCarga.New do begin tpUnidCarga := ucOutros; idUnidCarga := ''; with lacUnidCarga.New do nLacre := ''; qtdRat := 0; end; LinfUnidTransp.qtdRat := 0; Lperi := LInfCTe.peri.New; Lperi.nONU := ''; lperi.xNomeAE := ''; Lperi.xClaRisco := ''; Lperi.grEmb := ''; Lperi.qTotProd := ''; Lperi.qVolTipo := ''; LinfCTe.infEntregaParcial.qtdTotal := 0; LinfCTe.infEntregaParcial.qtdParcial := 0; with LinfCTe.infNFePrestParcial.New do chNFe := ''; //=============>CT<============================= LinfCT := LInfMunDescarga.infCT.New; LInfCT.nCT := ''; LInfCT.serie := 0; LinfCT.subser := 0; LinfCT.dEmi := Now; LinfCT.vCarga := 0; LInfUnidTransp := LInfCT.infUnidTransp.New; LinfUnidTransp.tpUnidTransp := utOutros; LinfUnidTransp.idUnidTransp := ''; with LinfUnidTransp.lacUnidTransp.New do nLacre := ''; with LinfUnidTransp.infUnidCarga.New do begin tpUnidCarga := ucOutros; idUnidCarga := ''; with lacUnidCarga.New do nLacre := ''; qtdRat := 0; end; LinfUnidTransp.qtdRat := 0; //=============>NF-e<============================= LinfNFe := LInfMunDescarga.infNFe.New; LinfNFe.chNFe := ''; LinfNFe.SegCodBarra := ''; LinfNFe.indReentrega := ''; LInfUnidTransp := LInfNFe.infUnidTransp.New; LinfUnidTransp.tpUnidTransp := utOutros; LinfUnidTransp.idUnidTransp := ''; with LinfUnidTransp.lacUnidTransp.New do nLacre := ''; with LinfUnidTransp.infUnidCarga.New do begin tpUnidCarga := ucOutros; idUnidCarga := ''; with lacUnidCarga.New do nLacre := ''; qtdRat := 0; end; LinfUnidTransp.qtdRat := 0; Lperi := LInfNFe.peri.New; Lperi.nONU := ''; lperi.xNomeAE := ''; Lperi.xClaRisco := ''; Lperi.grEmb := ''; Lperi.qTotProd := ''; Lperi.qVolTipo := ''; //=============>MDF-e<============================= LInfMDFeTransp := LInfMunDescarga.infMDFeTransp.New; LInfMDFeTransp.chMDFe := ''; LInfMDFeTransp.indReentrega := ''; LInfUnidTransp := LInfMDFeTransp.infUnidTransp.New; LinfUnidTransp.tpUnidTransp := utOutros; LinfUnidTransp.idUnidTransp := ''; with LinfUnidTransp.lacUnidTransp.New do nLacre := ''; with LinfUnidTransp.infUnidCarga.New do begin tpUnidCarga := ucOutros; idUnidCarga := ''; with lacUnidCarga.New do nLacre := ''; qtdRat := 0; end; LinfUnidTransp.qtdRat := 0; Lperi := LInfMDFeTransp.peri.New; Lperi.nONU := ''; lperi.xNomeAE := ''; Lperi.xClaRisco := ''; Lperi.grEmb := ''; Lperi.qTotProd := ''; Lperi.qVolTipo := ''; Caso utilize ACBrMonitorPLUS ou ACBrLib: ; Utilize tags abaixo para Adicionar CTes Relacionados [infCTe001001] chCTe= SegCodBarra= indReentrega= [peri001001001] nONU= xNomeAE= xClaRisco= grEmb= qTotProd= qVolTipo= [infEntregaParcial001001] qtdTotal=0 qtdParcial=0 [infUnidTransp001001001] idUnidTransp= tpUnidTransp= qtdRat= [lacUnidTransp001001001001] nLacre= [infUnidCarga001001001001] idUnidCarga= tpUnidCarga qtdRat= [lacUnidCarga001001001001001] nLacre= ; Utilize tags abaixo para Adicionar NFes Relacionadas [infNFe001001] chNFe= SegCodBarra= indReentrega= [peri001001001] nONU= xNomeAE= xClaRisco= grEmb= qTotProd= qVolTipo= [infUnidTransp001001001] idUnidTransp= tpUnidTransp= qtdRat= [lacUnidTransp001001001001] nLacre= [infUnidCarga001001001001] idUnidCarga= tpUnidCarga qtdRat= [lacUnidCarga001001001001001] nLacre= ; Utilize tags abaixo para Adicionar MDFes Relacionados [infMDFeTransp001001] chMDFe= indReentrega= [peri001001001] nONU= xNomeAE= xClaRisco= grEmb= qTotProd= qVolTipo= [infUnidTransp001001001] idUnidTransp= tpUnidTransp= qtdRat= [lacUnidTransp001001001001] nLacre= [infUnidCarga001001001001] idUnidCarga= tpUnidCarga qtdRat= [lacUnidCarga001001001001001] nLacre= Eu preenchi estas informações, mas mesmo assim elas não foram geradas no meu XML. Para entender isso, primeiro precisamos observar as regras de validação das rejeições 638, 639 e 540: Veja que de acordo com o Tipo do Emitente (tpEmit) que foi preenchido no MDF-e, um determinado tipo de documento não pode ser referenciado. As soluções do ACBr já fazem estas tratativas internamente. Então se, por exemplo, você preencheu o valor 1 para o tpEmit, e preencheu as informações de uma NF-e referenciada, essas informações não serão adicionadas no XML. Você deve corrigir o tpEmit.
