Ir para conteúdo
  • Cadastre-se

Paulofrlima

Membros
  • Total de ítens

    27
  • Registro em

  • Última visita

Últimos Visitantes

O bloco dos últimos visitantes está desativado e não está sendo visualizado por outros usuários.

Paulofrlima's Achievements

Explorer

Explorer (4/14)

  • First Post
  • Collaborator Rare
  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

10

Reputação

2

Community Answers

  1. Na verdade é uma pratica bem comum para o setor de Contabilidade.
  2. Bagunçava sim... Estava com a cadeia toda quebrada, pois o último NSU entregue ao meu sistema não era mais o último NSU que o SEFAZ disponibilizou para o CNPJ. Este é o ponto da questão. Pois outro programa entrava na sequencia e baixava outros NSU´s antes de mim. Assim, toda vez que eu tentava passar meu ultimo NSU o SEFAZ retornava com erro "Rejeicao: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitacoes subsequentes. Tente apos 1 hora)". Algumas vezes eu conseguia entrar e baixar, pois já havia se passado 1 hora que meu sistema e a segunda aplicação haviam consumido o WS. Perceba que é exatamente o comportamento que sua aplicação está recebendo... Ou seja: para o SEFAZ não interessa qual IP/aplicação está buscando as informações, conforme NT ela disponibiliza por CNPJ. Se existe mais de uma aplicação concorrendo com mesmo CNPJ esta nova versão (SEFAZ) não faz distinção e bloqueia informando que você já baixou recentemente estes documentos...
  3. Olha... minha situação era EXATAMENTE igual a de vc´s... Busquem... Revirem... pois tem outra aplicação fazendo concorrência com a de vcs... Minha aplicação está rodadndo de 16/03 sem nenhuma rejeição a cada 1:10h... O pessoal do SEFAZ me confirmou que haviam acessos indevidos, me indicando inclusive os horários de acessos. Inicialmente também rejeitei esta hipótese pois o contator "jurava" não fazer acessos... Pois é a maquina dele fazia e ele nem sabia...
  4. Não, se perceu a cadeia vc deve aplicar "0" ou um NSU muito antigo (abaixo de 90 dias)... Suponha: ultimo nsu consultado corretamente pela sua aplicação: 23455. e sua aplicação irá aguradar 1h para buscar novos... Uma segunda aplicação entrou em paralelo e baixou arquivos de 23455 a, suponhamos, 23460. Quando sua aplicação tentar consultar o 23455, ou seja um NSU relativamente recente, vc toma rejeição, pois para o SEFAZ o CNPJ já baixou recente estes documentos...
  5. "Mas, a contabilidade usa o certificado da empresa, isso iria resolver?" Não seria prático, pois todos os seus fornecedores teriam que colocar o CNPJ/CPF´s dos atores envolvidos (no caso o CNPJ do seu contator. Pois aí o contator acessaria pelo CNPJ do contator com o certificado do contador e não pelo CNPJ da empresa com certificado da empresa. De acordo com a NT cada CNPJ pode ter somente 1 acesso via tag distNSU. Sugestão: Faça um único recebimento de 100% da documentação. Internamente redistribua aos atores interessados (ao contador por exemplo).
  6. Amigos, Compartilhando informações: Aqui mesmo caso, SEFAZ retornou chamados informando acesso indevido. Fiquei monitorando o trafego de saída para o IP do SEFAZ. Descobrimos que um "mensageiro" utilizado por um programa de terceiros aqui também estava acessando o serviço distribuicaoDFe com uma frequencia de 20 min (Obviamente bloqueando tudo)... Desligado o mesageiro tudo voltou ao normal.
  7. Boa tarde, amigos, Desculpe, estava tratando outros assuntos e fiquei afastado... Segue link: https://www.gov.br/receitafederal/pt-br/canais_atendimento/fale-conosco/empresa/sped/nf-e Abaixo última conversa com eles: //------------------------------------- Prezado, Para o caso 1--> foi identificada a situação que estava causando o problema e já ajustada. Para o caso 2 --> é mesmo uso indevido do usuário. Só tem um IP consultando. Mas, desde às 12h aparentemente não estão recebendo uso indevido. Acredita-se que vocês tenham realizado os ajustes necessários. Atenciosamente, Equipe NF-e Bom dia, O setor de contabilidade é interno aqui na XXX. Testei a hipótese de um possível segundo acesso. Somente uma maquina está fazendo o acesso. Um detalhe, somos um grupo empresarial assim, faço a consulta em mais de um CNPJ. Para o CNPJ: XXXXXXXXXXXXXX Estou recebendo o cStaT=656 - Erro: Rejeicao: Consumo Indevido (Deve ser aguardado 1 hora para efetuar nova solicitacao caso nao existam mais documentos a serem pesquisados. Tente apos 1 hora) em vez de receber o cStaT=137 - Nenhum Documento. Estou respeitando o tempo de 2 horas entre consultas. Fiz um acesso via TAG: consNSU e o sistema me retornou maxNSU = ultNSU confirmando não haver mais documentos. Para um terceiro CNPJ (XXXXXXXXXXXX) não foi feito nenhum acesso desde sexta, hoje pela manhã já recebi a rejeição: cStaT=656 - Erro: Rejeicao: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitacoes subsequentes. Tente apos 1 hora) Tem mais algo que eu possa fazer? No aguardo,
  8. Bom dia, Aqui segue o mesmo erro... Segue retorno do SEFAZ: //---------------------------- Prezado, Como a mensagem de bloqueio informa que a sequência de NSU não está sendo seguida e você acredita não ter quebrado a cadeia, a hipótese possível que geralmente ocorre é que há mais de um IP acessando o disNSU pela empresa, com sequência de NSU distinta. Verifique se não tem outra área da empresa/prestador de serviços com certificado para acessar o serviço. //---------------------------- A contabilidade é interna aqui, somente eu estou acessando... Tentarei contato novamente com SEFAZ...
  9. Este é o padrão de erro aparente... Protocolo aberto, mas acredito que só na segunda...
  10. Pois é o problema é que continua retornando rejeição quando consultado UltNSU com ultNSU = 0 (obviamente aguadando o tempo "de castigo" acima de 1 hora). Os outros serviços funcionam corretamente (por chave e NSU específico) dentro do limite de 20 pesq/h.
  11. Não é, estou com o mesmo problema... Tentei ajustar o "Nº de Tentativas" para 1, mas estou com o mesmo problema...
  12. Olá Suzana, Poderia explicar melhor a sua solução? onde se faz este ajuste?
  13. Sim, tentei sim, mas meu nível de conhecimento não é tão profundo a ponto d econseguir interceptar este possível erro, por isso estou apelando ao forum.
  14. Sim, atualizo pelo SVN a pasta ACBr toda, e incluvise, baixei 100% novamente para ter certeza que não havia ficado nada para trás. Não ocorreu nenhum erro de compilação essa é a questão...
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.