Pesquisar na Comunidade

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.

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.

Estou tentando fazer a Distribuição DF-e por ultimo NSU MG, mas só ocorre CONSUMO INDEVIDO, mesmo aguardando o prazo. Já tentei com o CNPJ da minha empresa (tenho notas emitidas no CNPJ), com o meu CPF (tenho notas emitidas no meu CPF este mês). Meus clientes também não estão conseguindo. Tentei pelo demo ACBrNFe e também ocorre a mesma rejeição (lembrando que para testar com o demo aguardei até 24 hs após ter dado Consumo Indevido no meu aplicativo). Ele já dá consumo indevido logo na primeira tentativa.

Bom dia Sr.s (as). Estou com um problema a respeito das consultas de NF-e's recebidas onde obtenho o seguinte retorno da SEFAZ... 656 - NSU: 000000000057186 - Msg: Documento(s) localizado(s) Rejeição: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitações subsequentes. Tente apos 1 hora) Tentando Novamente... 656 - NSU: 000000000000000 - Msg: Rejeicao: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitacoes subsequentes. Tente apos 1 hora) Rejeicao: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitacoes subsequentes. Tente apos 1 hora) Tentando Novamente... Em prol da resolução, verifiquei que existe um certo limite de consultas no webservice da sefaz (O limite é de 600 consultas a cada 5 minutos para um mesmo certificado) Fonte:https://www.oobj.com.br/bc/article/rejeição-656-consumo-indevido-como-resolver-4.html Alguém poderia confirmar se é verídica essa fonte de dados ? ou já tratou alguma situação semelhante... Agradeço a atenção!!!

Boa tarde, estou tendo o seguinte problema Em um dos meus clientes está ocorrendo o erro "Consumo Indevido" no retorno do método "ACBrNFe1.WebServices.Envia" Antes de enviar o xml, chamo os métodos Assinar e Validar, nessa ordem respectivamente O problema ocorre esporadicamente, em média 2 vezes por dia, em alguma das lojas da rede desse cliente O volume de geração de Nfe dele é um pouco superior a média que meus outros clientes geram O maior problema é o seguinte. Como acontece o erro de consumo indevido, não tenho acesso ao xml de retorno da Sefaz. Quando vou consultar o status dessa Nfe pela chave, é retornado o status "Autorizado o Uso". Quando acontece isso, preciso baixar o xml manualmente. Isso aconteceu com mais alguém? Vocês sabem informar se tem alguma forma de recuperar esse xml, ou o que pode estar causando isso? Acredito que não seja nenhum problema no layout do xml. Obrigado

Olá pessoal. Venho recorrer a vocês sobre um problema que estou enfrentando, e está se tornando insustentável nos clientes. Poise bem na empresa onde eu trabalho, atendemos a alguns supermercados. Desenvolvemos um sistema monitor de notas, onde fica uma Thread/Timer rodando e verificando se existem notas por serem transmitidas. Cada caixa do supermercado utiliza uma série distinta. E cada caixa tem seu monitor de envios independente, ou seja, se um caixa parar, os demais continuam funcionando. O que vem acontecendo com frequência é o aumento de casos de "consumo indevido"... Andei lendo as notas técnicas a respeito, e já estou ciente que o erro se dá ao número de requisições para o mesmo documento em um curto espaço de tempo... Porém existem algumas situações rotineiras que acontecem neste clientes... uma delas, é ao transmitir a nota fiscal pela primeira vez, em alguns casos a aplicação demora a obter resposta, e acaba recebendo cStat = 0, e xMotivo = vazio... neste caso eu não sei afirmar se é algo de errado com a sefaz do meu estado, ou se pode ser a conexão com a internet do cliente... a aplicação demora a obter resposta quando recebe o cStat = 0... e quando isso acontece imediatamente "para não segurar o andamento do caixa" eu imprimo a nota fiscal em modo offline... e no banco de dados eu mudo o status desta nota como pendente... dai então tenho outra fila de processamento em segundo plano... que tenta transmitir estas notas pendentes quando não há notas novas na fila de processamento.... "já mais executo 2 transmissões simultaneamente"... o problema começa a acontecer quando tento transmitir estas notas que estão pendentes... tenho como hábito consultar a nota antes do envio... se a nota já estiver na receita eu pego chave e protocolo e dou por encerrada... se a nota não estiver na receita então eu executo a transmissão novamente.... este processo de consultar e executar a transmissão na maior parte dos casos gera consumo indevido.. Resumindo tudo o sistema vinha funcionando corretamente até 1 mês atrás... começou recentemente... não sei se estou lidando com uma instabilidade de conexão nos clientes, ou estou lidando com alguma eventual mudança de regras na sefaz do meu estado... estou compartilhando com vocês esta situação pois estou ficando desamparado de alternativas, já tentei muitas coisas, porém não estabiliza... estou pensando em desistir de consultar as notas... tentar enviar todas, e somente o que der duplicidade eu consulto... não sei se é certo ou errado fazer isso... Lembrando que só acontece isso em supermercados com vários caixas, onde o volume de notas é muito grande. Alguém teria alguma sugestão ou resposta? Fico agradecido a todos pela atenção. E aos administradores, me perdoem se eu dupliquei o assunto, porém não encontrei algo exatamente semelhante ao que acontece no meu caso. Obrigado.

Bom dia. Quando envio algumas notas me retorna 656 - Consumo indevido, sendo que não foram feitas várias tentativas em curto intervalo de tempo. Alguém já passou por isso e tem alguma solução? Por exemplo nnf=510 no anexo. Inclusive nas próximas tentativas é retornado 539 (duplicidade), portanto a SEFAZ absorveu mas retornou consumo indevido. Obrigado! consumoindevido.txt

Olá. Já aconteceu o seguinte problemas algumas vezes em minha aplicação: Ao tentar enviar a NFe para SEFAZ, me retorna o erro "Consumo Indevido", a NFe é gerada na SEFAZ porém o XML não é gerado em minha máquina. Gostaria de uma forma de buscar esse XML utilizando o ACBR. Minha aplicação é em Delphi Obrigado!

Estou implementando o Manifesto no sistema da empresa em que trabalho. Ao efetuar uma série de testes, obtive a rejeição 656. Decidi aproveitar o ocorrido, para tratar esta rejeição. Ao analisar o fonte da ACBrNfeWebServices, no método TNFeConsNFeDest.Executar, percebi que o Result só será True, quando o cStats do retorno da operação for 137 ou 138. No método TACBrNFe.ConsultaNFeDest, da unit ACBrNFe, se o resultado do método anterior for False, ele vai dar um Raise EACBrNFeException. Essa exceção está vindo sem mensagem, impossibilitando a identificação do erro no meu programa. Gostaria de saber se alguém já teve este problema, e gostaria de saber se tem alguma solução, sem precisa editar os fontes da ACBr.

Olá. Alguém sabe, como a SEFAZ faz esse tipo de bloqueio? Tipo, se é por CNPJ, por Certificado digital, por IP...