Pesquisar na Comunidade
Showing results for tags 'rejeição'.
Encontrado 117 registros
-
Olá pessoal! Em sua atualização mais recente na Nota Técnica 2023/004 a regra de validação para este rejeição ficou desta forma: Conforme descrito, se você está recebendo está rejeição, significa que seu arquivo XML possui o tPag com o valor 03, 04 ou 17, mas não possui o grupo de cartões (grupo card no XML). Quais são os campos que compõe este grupo você se pergunta. Para isso, podemos conferir na mesma nota técnica, vejam: Como eu faço para preencher estes campos nas soluções ACBr? Se você está utilizando o componente nativo para Delphi ou Lazarus as propriedades podem ser preenchidas da seguinte forma: var NotaF: NotaFiscal; InfoPgto: TpagCollectionItem; begin NotaF := ACBrNFe.NotasFiscais.Add; //Preenche as demais informações da NFe... InfoPgto := NotaF.NFe.pag.New; InfoPgto.tPag := InfoPgto.tpIntegra := InfoPgto.CNPJ := InfoPgto.tBand := InfoPgto.cAut := InfoPgto.CNPJReceb := InfoPgto.idTermPag := end; Agora caso esteja utilizando o ACBrMonitorPLUS ou a ACBrLibNFe, para adicionar as informações, o arquivo INI deve ser preenchido assim: [pag001] tPag= tpIntegra= CNPJ= tBand= cAut= CNPJReceb= idTermPag= Vale mencionar... Embora de acordo com a NT, do grupo card, somente os campos tpIntegra e cAut sejam obrigatórios, não há problema nenhum em preencher as demais informações. Ter elas registradas no arquivo XML, pode auxiliar em um controle de informações e torna a operação mais transparente para o destinatário. Também temos indícios de que ao menos a Sefaz do Paraná, espera receber mais campos além do tpIntegra e do cAut, como pode ser visto no tópico abaixo:
-
- 2
-
-
- baseconhecimento
- base conhecimento
- (e 4 mais)
-
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.
-
Olá pessoal! No dia 01/07/2024 entrou em vigor no ambiente de produção as regras de validação da versão mais recente da Nota Técnica 2023/004. Essa versão alterou a regra de validação que devolvia a rejeição 391, dando a ela o texto: Quando está regra entrou em vigor, muitos contribuintes começaram a receber no estado de Minas Gerais a rejeição 391, o que no início assustou muitos colegas, visto que a UF não havia publicado legislação que dessa a entender que adotaria a implementação da mesma. Na época, a AFRAC buscou mais informações junto a Sefaz e recebeu o seguinte retorno: No dia 16/09/2024, ao acessar o portal SPED MG o seguinte aviso foi exibido indicando que a regra será reativada no dia 01/10/2024:
- 1 reply
-
- 3
-
-
- sefazmg
- rejeicao391
- (e 6 mais)
-
Rejeição 296: Certificado Assinatura erro no acesso a LCR. Como resolver?
um tópico no fórum postou Diego Foliene NF-e/NFC-e
Antes de mais nada é preciso entender o que é LCR. Como todos sabem, quando enviamos um documento fiscal para o web service da Sefaz, o mesmo deve ter sido assinado por um certificado digital que também é utilizado na comunicação propriamente dita para garantir a segurança e a veracidade dessa troca de informações entre o emissor e o servidor de destino. Este certificado digital usado pelo emissor, possui uma data de início e fim de validade, então você pode ter um certificado que ainda não está valido ou com validade expirada, tornando o certificado inválido. No entanto, as vezes, por algum outro fator, como por exemplo, extravio do certificado digital ou alteração do contrato social, pode ser que o certificado deixe de ser válido mesmo ainda estando dentro do período de validade vigente. Quando isso acontece o certificado é adicionada na Lista de Certificados Revogados (LCR) para dizer a todos que a consultarem que ele não é mais válido. Entendendo a rejeição. Agora que entendemos o que é LCR, vamos voltar a rejeição: Vejam que coloquei a palavra "acesso" em destaque. Isso porque quem a faz a consulta na LCR é o servidor que está recebendo a comunicação, ou seja, é o servidor de destino quem consulta a LCR, o que significa que a rejeição 296 está nos dizendo que o servidor da Sefaz não conseguiu acessar a LCR para consultar se o certificado que está comunicando é válido. E como eu resolvo? Infelizmente, este é um erro em que não se pode fazer muita coisa do lado da software house, pois é um erro que ocorreu do lado do web service da Sefaz ou do lado da própria certificadora digital. Portanto, se você está recebendo esta rejeição, o curso de ação mais indicado é: Orientar seu cliente para que ele possa entender que o problema é na Sefaz ou na certificadora digital, sendo assim, um problema externo. Abrir um Fale Conosco junto a Sefaz respectiva para deixá-los cientes do problema. Realizar novo teste após aguardar um período de tempo. -
Boa tarde. Estou tentando conciliar um CT-e emitido via EPEC, no ambiente de Homologação da Sefaz MT, só que sempre está retornando a rejeição a seguir: “402 - Rejeicao : XML da area de dados com codificacao diferente de UTF-8.” Já verifiquei o XML, inclusive no Validador de Mensagens do Projeto CT-e, e não acusa erro. - Ao tentar emitir um documento com os mesmos dados, mas forma de emissão 1 – Normal, é autorizado normalmente. - Ao tentar emitir um evento EPEC, o mesmo é criado normalmente. - Ao tentar conciliar o CT-e (com tpEmiss = 4) referente a EPEC anterior, sempre é retornada a rejeição 402. Entrei em contato com o atendimento da Sefaz MT, mas não responderam mais. Expliquei a situação, pedindo para verificarem também se poderia ser algo relacionado ao ambiente, conforme e-mail abaixo: Analisei até o código-fonte (\Fontes\ACBrDFe\ACBrCTe\ACBrCTe.pas linha 338 em diante) e não percebi nada diferente: // Passo 2 calcular o SHA-1 da string idCTe se o Tipo de Emissão for EPEC ou FSDA if TipoEmissao in [teDPEC, teFSDA] then begin // Tipo de Emissão em Contingência SSL.CarregarCertificadoSeNecessario; sign := SSL.CalcHash(idCTe, dgstSHA1, outBase64, True); Passo2 := '&sign=' + sign; sEntrada := sEntrada + Passo2; end; Result := urlUF + sEntrada; Em anexo XMLs: CT-e com emissão Normal: 51240706137422000190570010000000311680036048-cte-normal.xml Evento EPEC: 11011351240706137422000190570010000000254289813233001-procEventoCTe.xml CT-e com tipo de emissão EPEC: 51240706137422000190570010000000254289813233-cte-epec.xml Envio do lote: 25-env-lot.xml e 25-env-lot-decodado.xml Rejeição retornada: 25-pro-lot.xml Caso alguém tenha passado por essa situação e possa contribuir com algo, fico grato, mas acredito não ter algo a ver com o ACBr, já que utilizamos a emissão e conciliação de EPEC normalmente em ambiente de Produção, pelo menos até o momento. -
Rejeição CT-e não encontrado na base de dados da sefaz
um tópico no fórum postou joao.nogueira ACBrCTe
Boa tarde! Após realizar as alterações e e atualizado os schemas para a versão 4.00 do CT-e, ao tentar transmitir a nota está dando rejeição(CT-e não consta na base de dados da SEFAZ), não deixando transmitir. Aparentemente, ele não está nem chegando a enviar a nota para a sefaz, onde já retorna a mensagem da rejeição. Vou deixar em anexo o XML. 35240221428290000149570020000000881000000884-cte.xml 1-env-lot.xml -
bom dia amigos, tenho um cliente que emiti varias notas em sequencia, e tem recebido a mensagem de consumo indevido com frequência, eu gostaria de saber se alguém tem passado por isso também ??? gostaria de saber se pode haver alguma coisa que posso melhorar para evitar isso, por exemplo: sempre seto versao e modelo do documento antes do envio: NFe.SetVersaoDF(), NFe.SetModeloDF(), sempre consulto o status antes do envio da nfe: NFe.StatusServico() caso alguém possa ajudar ou contribuir para tentar melhorar essa questão, agradeço.
-
XML de retorno: <retorno><mensagem><codigo>00209 - Já consta uma NFSe para o referido prestador de serviço com o mesmo IDENTIFICADOR de arquivo</codigo></mensagem><identificador>nfse</identificador><numero_nfse>5297</numero_nfse><serie_nfse>1</serie_nfse><data_nfse>06/11/2023</data_nfse><hora_nfse>16:53:41</hora_nfse><arquivo_gerador_nfse>452-ger-nfse.xml</arquivo_gerador_nfse><nome_arquivo_gerado_eletron>452-ger-nfse.xml</nome_arquivo_gerado_eletron><link_nfse>http://sync.nfs-e.net/datacenter/include/nfw/nfw_imp_notas.php?codauten=0180030001856541</link_nfse><cod_verificador_autenticidade>0180030001856541</cod_verificador_autenticidade></retorno> porem em acbrlibxml2 na funcão function xmlParseDoc(const cur: xmlCharPtr): xmlDocPtr; begin if InitLibXml2Interface and Assigned(_xmlParseDoc) then Result := _xmlParseDoc(cur) //Retorna nil! else Result := nil; end; e gera essa mesangem: X999 - Erro de Conexão: Input is not proper UTF-8, indicate encoding ! Bytes: 0xE1 0x20 0x63 0x6F Ja atualizei o repositório.
-
Bom dia pessoal, tudo bem? Estou tentando realizar o encerramento de um MDF-e utilizando E-CPF de produto rural, tanto a emissão do MDF-e quanto a consulta funcionam mas o encerramento retorna o seguinte erro: "CNPJ-Base do Emitente difere do CNPJ-Base do Certificado Digital" Novamente, ocorre apenas na operação de encerramento do documento. Testamos tanto com o ACBrLib em C# quanto em Delphi, ambos retornam a mesma rejeição. Como eu poderia proceder nessa questão? -
Erro validação ValidarRegrasdeNegócio rejeição 610
um tópico no fórum postou tiautomacao NFe/NFCe - Nota Fiscal Eletrônica
Bom dia. Observei que está com um erro no ValidarRegrasdeNegocio, ao verificar os valores referente a rejeição 610 - Total da NF difere do somatório dos Valores que compõe o valor total da NF. A tag vNF já desconta o vICMSDeson... porém, na validação, o ACBr está comparando esse vNF com o vNF + vICMSDeson... com isso, aparece a diferença de justamente o valor do ICMS Desonerado. Segue um XML que estou tendo a rejeição, e se for analisar as TAGs, está tudo correto. Segue tbm um vídeo onde mostro os valores dentro da validação do ACBr. Att. Obrigado desde já. Gravar_2023_10_02_10_19_48_684.mp4 nf_160236_0210.xml -
Rejeicao 482 - Codigo do Municipio do Destinatario diverge do cadastrado na UF
um tópico no fórum postou valterpatrick ACBrNFe
Pessoal, eu vi que teve um caso dia 06/07/2023 de tentarem emitir NFe, mas dar a rejeição 482. Nesta situação apresenta que a cidade do cliente que você está emitindo a NFe está divergente com a cidade no Sintegra. Esta é uma situação que está acontecendo quando é pessoa física com inscrição estadual de produtor rural e a cidade que você está emitindo é diferente da cadastrada. A solução NÃO é alterar a cidade da pessoa, mas sim emitir em CONTINGÊNCIA. A Sefaz de MG está em contingência a principio até dia 13/07/2023 e se você emitir em SVCAN vai conseguir emitir normal. Esta situação aconteceu comigo agora a pouco. Ai estou postando a solução aqui por que vi orientações diferentes: -
Rejeição 606 - Rejeição: Segundo Código de Barras deve ser informado para NF-e em contingência
um tópico no fórum postou maiko_bito ACBrMDFe
Boa tarde. Pessoal já tenho o MDFe desenvolvido e funcionando a algum tempo, a partir do componente do ACBr... porém hoje em um determinado cliente deu a seguinte rejeição ao transmitir um MDFe 606 - Rejeição: Segundo Código de Barras deve ser informado para NF-e em contingência seguido desta mensagem ele da uma das chaves das NFes anexadas ao MDFe, quando consulto essa chave, na receita ta normal, autorizada em ambiente normal... não compreendi por que da mensagem de contingência. -
Bom dia pessoal, Estou com um caso um pouco atípico, onde aconteceu o seguinte: Foi emitida uma NFe com o número 283, porém por erro técnico foi emitida na filial errada, causando rejeição, pois essa filial onde a NFe foi emitida já havia utilizado a numeração 283. Dessa forma, tentou-se inutilizar essa nota, porém não conseguimos, pois em teoria a inutilização serve para notificar à SEFAZ que um número não será utilizado, e a numeração 283 foi sim utilizada e autorizada, por engano foi emitida uma nova NFe 283 sobre a que já existia. Nesse caso, a dúvida é a seguinte: Existe algum problema em deixar a NFe rejeitada "para sempre"? O que fazer nesta situação? Agradeço desde já!
-
Rejeição Banco Do Brasil: 47-Título Tem Valor Diverso Do Informado
um tópico no fórum postou Visitante ACBrBoleto
Olá pessoal, Estou implementando o envio de remessa e recebimento de retorno do Banco do Brasil, porém os boletos de teste que estou enviando por remessa não estão sendo registrados, conforme segue: Ocorrência: 03-Comando recusado Motivo rejeição: 47-Título tem valor diverso do informado Convênio: 7 posições Carteira: 17 Variação: 019 Layout remessa e retorno: CNAB 240 Pesquisei no fórum, na internet e não encontrei nada sobre como solucionar esta rejeição 47. Liguei pro atendimento do Banco do Brasil e também não souberam me informar, então me pediram pra emitir outro teste para verificar se não foi alguma "inconsistência"... Emiti outro teste e rejeitou de novo. No fim, gerei outro arquivo de remessa e enviei para análise (o que pode demorar). O interessante é que já havia enviado arquivos de remessa direto para análise e o Banco do Brasil homologou. Alguém teria alguma ideia de como solucionar? Obrigado. -
Bom dia, caros colegas. Gostaria de passar uma situação para verificarem na função ValidarRegrasdeNegocios. Creio que o bloqueio está errado para MG. Ao gerar uma NFe com o campo indpres = 2 ou 3, não deveria retornar a rejeição 873, conforme NT 2021.004 versão 1.33. Meus fontes do ACBr estão atualizados e mesmo assim, está bloqueando. Segue em anexo imagem da parte do manual que contém esta exceção. Obrigado!
-
Boa tarde pessoal, Ao ler um arquivo de retorno do banco Bradesco, um título está com a seguinte ocorrência "03-Entrada rejeitada". Busquei na internet, e o motivo para esta rejeição pode ser vários dados que esteja errado, fica algo um tanto genérico. Existe algum método ou propriedade do componente ACBrBoleto que eu consigo visualizar o detalhamento dessa ocorrência, como por exemplo, o código da rejeição, os dados que estão incorretos, etc? No documento do banco, diz o seguinte "Entrada Rejeitada (verificar motivo nas posições 319 a 328)", mas eu gostaria de saber se o componente já lê essa informação e qual propriedade ou método responsável por isso, para que eu possa ter esse detalhamento para facilitar encontrar onde está o problema. Grato.
-
Problemas para saber o numero do ultimo NSU baixado.
um tópico no fórum postou Gabriel Fernando Lopes Dúvidas Gerais sobre o ACBr
Desde fevereiro de 2022 não conseguimos baixar NSU pela função DistribuicaoDFePorUltNSU (utilizamos a função desde março de 2019 sem problemas). Sempre aparece a rejeição "Rejeição: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitações subsequentes. Tente após 1 hora)". A principio achamos que era problema no sefaz e ficamos um tempo sem baixar NSU. No entanto, mesmo ficando uma semana sem tentar baixar, a mensagem de rejeição sempre é a mesma. Então suspeitamos que poderíamos ter perdido um bloco de NSU e portanto estaríamos usando o ultNSU errado. Tentamos essa semana enviar o ultNSU como 0 (zero) para receber o bloco mais antigo existente no ambiente nacional e também para sabermos qual o ultNSU e o maxNSU. No entanto a resposta foi a mesma, "Rejeição: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitações subsequentes. Tente após 1 hora)". Existe alguma outra maneira de contornar esse problema? -
Pessoal, ao emitir uma nota, está retornando a rejeição 225: "Falha no Schema XML do lote de NFe". Está acontecendo isto quando tem PISTST e CofinsST, creio eu que é por conta das tags indSomaPISST e indSomaCOFINSST. <?xml version="1.0" encoding="UTF-8"?><retEnviNFe xmlns="http://www.portalfiscal.inf.br/nfe" versao="4.00"> <tpAmb>2</tpAmb> <verAplic>14.4.30-OR3</verAplic> <cStat>225</cStat> <xMotivo>Rejeicao: Falha no Schema XML do lote de NFe</xMotivo> <cUF>31</cUF> <dhRecbto>2021-08-28T10:37:25-03:00</dhRecbto> </retEnviNFe> Falha na validação Schema.xml
-
Olá, boa tarde! Estou tendo dificuldades em implementar a emissão de NFSe para o município de Itaquaquecetuba, atualmente utilizando provedor SilTecnologia. Todas as minhas tentativas resultam no erro "O campo Nome do Tomador e obrigatorio". Conferi o layout e não encontro nada de errado. Tenho o sistema funcionando perfeitamente no município de Itapevi, que também utiliza SilTecnologia, porém, em Itaquaquecetuba é só rejeição. Alguém passou por algo parecido e/ou tem uma sugestão? Os XMLs estão em anexo. Obrigado. 12-env-lot.xml NS21072915014612195059000161000000001.xml 12-rec.xml -
Cancelamento da NFe não aparece no site da fazenda
um tópico no fórum postou Pratic Sistemas ACBrMonitorPLUS
bom dia amigos, por duas vezes aconteceu com o cancelamento da nfe, o sistema fez o cancelamento normal, foi gerado o xml de retorno com protocolo e confirmação do cancelamento, porém no site da fazenda ao fazer a consulta não consta o evento de cancelamento. alguém mais teve esse problema ??? houve alguma alteração em relação a cancelamento de nfe ??? no aguardo, até mais. -
Rejeição 539: Duplicidade de NF-e, com diferença na Chave de Acesso - Estado Goiás
um tópico no fórum postou valterpatrick ACBrNFe
Pessoal, no dia 31/01/2021 às 20:30 um cliente emitiu a nota fiscal número 219. 5 minutos depois o cliente foi tentar emitir a 220 e não conseguiu, deu a rejeição 539. Todas as notas que ele tenta emitir é apresentado esta mensagem. Já tentamos emitir a número 250 e apresenta a mesma mensagem de erro. Ao entrar no portal da Sefaz de GO (http://nfe.sefaz.go.gov.br/nfeweb/sites/nfe/consulta-publica/principal) aparece só até a nota número 219. No ambiente nacional não consigo encontrar as notas fiscais pela chave de acesso e já ouvi de um outro colega programador de GO que lá ele tem bastante erro de duplicidade, mas este caso está acontecendo apenas para um cliente de GO até o momento. Eu já olhei os arquivos XML gerados, assim como os arquivos de retorno e não sei o que fazer. -
Estamos implementando ferramentas para automatizar a busca de NFe pelo ambiente nacional, usando a função DistribuicaoDFePorChaveNFe. Primeiramente pegamos e alteramos o código de Manifestação de Destinatário no exemplo em ACBR\Exemplos\ACBrDFe\ACBrNFe\Delphi: Nfe.EventoNFe.Evento.Clear; with Nfe.EventoNFe.Evento.Add do begin InfEvento.cOrgao := 91; infEvento.chNFe := Chave; infEvento.CNPJ := CNPJ; infEvento.dhEvento := now; infEvento.tpEvento := teManifDestConfirmacao; end; Nfe.EnviarEvento(StrToInt(IDLote)); with Nfe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento do begin lMsg:= 'Id: '+Id+#13+ 'tpAmb: '+TpAmbToStr(tpAmb)+#13+ 'verAplic: '+verAplic+#13+ 'cOrgao: '+IntToStr(cOrgao)+#13+ 'cStat: '+IntToStr(cStat)+#13+ 'xMotivo: '+xMotivo+#13+ 'chNFe: '+chNFe+#13+ 'tpEvento: '+TpEventoToStr(tpEvento)+#13+ 'xEvento: '+xEvento+#13+ 'nSeqEvento: '+IntToStr(nSeqEvento)+#13+ 'CNPJDest: '+CNPJDest+#13+ 'emailDest: '+emailDest+#13+ 'dhRegEvento: '+DateTimeToStr(dhRegEvento)+#13+ 'nProt: '+nProt; end; ShowMessage(lMsg); ShowMessage(Nfe.WebServices.EnvEvento.RetWS); ShowMessage(Nfe.WebServices.EnvEvento.RetornoWS); ShowMessage(ACBrUtil.ConverteXMLtoUTF8(Nfe.WebServices.EnvEvento.RetornoWS)); Aparentemente a chave de NFe escolhida foi manifestada corretamente. Então em seguida pegamos e alteramos o código de Distribuição no exemplo em ACBR\Exemplos\ACBrDFe\ACBrNFe\Delphi: nfe.DistribuicaoDFePorChaveNFe(AcUFAutor,ACNPJCPF,AchNFe); ShowMessage(nfe.WebServices.DistribuicaoDFe.RetornoWS); ShowMessage(nfe.WebServices.DistribuicaoDFe.RetWS); O resultado é uma caixa de diálogo do ACBr contendo o motivo "Rejeicao: Falha no esquema xml", depurando o código tenho o retorno em xml: '<retDistDFeInt xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" versao="1.00" xmlns="http://www.portalfiscal.inf.br/nfe"><tpAmb>2</tpAmb><verAplic>1.1.9</verAplic><cStat>215</cStat><xMotivo>Rejeicao: Falha no esquema xml</xMotivo><dhResp>2019-04-02T15:10:38</dhResp><ultNSU>000000000000000</ultNSU><maxNSU>000000000000000</maxNSU></retDistDFeInt>' Verificamos e recolocamos os schemas mas a mensagem de erro persiste, verificamos no fórum e fora um post DistribuicaoDfe por Chave de Acesso de 20 de março de 2017, não achamos nenhuma referencia do que pode estar acontecendo. Alguém tem ideia do que pode estar errado?
-
Rejeição - Valor do Troco incorreto (VTroco)
um tópico no fórum postou Thiago Hesketh NFC-e - Nota Fiscal do Consumidor Eletrônica
Bom dia. Estou emitindo NFCe e o Sefaz está rejeitando informando que o valor do troco está incorreto. Pelos dados do XML, parece estar correto. Alguém consegue me sinalizar onde pode estar o problema? Obrigado. NFCe_Debug2.xml NFCe_Debug.xml -
Tudo bem senhores! Existe como baixar diretamente do servidor da receita uma lista atualizada com todos os erros (códigos de rejeições e descrição) dos documentos fiscais? Não encontramos na internet nenhum site onde essa lista esteja atualizada e confiável. Se alguém souber de algum link onde eu possa encontrar, agradeceria muito.
-
Olá, tenho um cliente com 6 cx e em todos eles haviam alguns cupons em contigencia que enviei normalmente, mas em apenas um cx ficaram alguns cupons com esse erro de rejeição 397 - Parametro do QR-Code diverge da nota fiscal. Olhei o xml e conferi os dados e não consegui visualizar nenhum erro. Alguem pode me ajudar , segue o xml em anexo. 52191129844292000120650030000530299004121885-nfe.xml
