Ir para conteúdo
  • Cadastre-se

dev botao

Consulta de documentos fiscais por - DistribuicaoDFePorUltNSU


Ver Solução Respondido por Renato Rubinho,
  • Este tópico foi criado há 892 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

Postado

Boa tarde!

Há algumas semanas viemos enfrentando problemas com a consulta de documentos fiscais na Sefaz.

Já o revisei o código atendo-me as instruções do tópico abaixo.

Ao consultar, caso recebamos o primeiro lote de 50 notas e o UltNSU seja menor que o MaxNSU, aguardasse o intervalo de 30 segundos e reiniciasse a consulta. Para CTe, utilizamos a mesma estrutura desse Bloco, a qual (para CTe) está funcionando perfeitamente.

As consultas são feitas pelo usuário mesmo, não deixamos o processo de forma automática (via thread ou timer), o Usuário clica em consultar e o sistema executa o bloco abaixo, assim que o sistema identifica um retorno com Status 137 ou 656, bloqueamos a consulta, reativando o botão 'Consultar' apenas 1h após o horário da última consulta que retornou um dos Status citado.

Este é o bloco responsável pela consulta das notas através do UltNSU.

/***************************************************************************************************************/

    repeat
      try
        ACBrNFe.DistribuicaoDFePorUltNSU(UFtoCUF(FEmpresaParametroVO.EstadoCidade),
                                         PegarNumeros(FEmpresaParametroVO.CNPJ),
                                         mUltNSUNFe);
      except //Deixar o sistema tratar o retorno
      end;

      var mRetornoDistDFe := ACBrNFe.WebServices.DistribuicaoDFe.retDistDFeInt;
      mStat      := mRetornoDistDFe.cStat;
      mMotivo    := mRetornoDistDFe.xMotivo;
      mUltNSUNFe := mRetornoDistDFe.ultNSU;
      mMaxNSUNFe := mRetornoDistDFe.maxNSU;

      if (mStat = 138) then
        begin
          InsereDfeSefazHistorico(mStat, mMaxNSUNFe, mUltNSUNFe, '55', mMotivo);
          InserirAlterar(mRetornoDistDFe);
          Result := True;
        end
      else if (mStat = 137) then
        begin
          InsereDfeSefazHistorico(mStat, mMaxNSUNFe, mUltNSUNFe, '55', mMotivo);
          Informa('Não há novos documentos a serem consultados!' + cgEnterEmString +
                  'A SEFAZ exige que a próxima consulta seja feita somente após o intervalo de 1h de espera.');
          BloqueiaBuscaSefaz(0, mStat);
          CarregarCadastro;
          Exit;
        end
      else
        begin
          InsereDfeSefazHistorico(mStat, mMaxNSUNFe, mUltNSUNFe, '55', mMotivo);

          var mErro := 'Falha ao realizar a consulta das notas fiscais.';
          if (mStat = 656) then
            mErro := 'Não há novos documentos a serem consultados!';

          Informa(mErro + cgEnterEmString + IntToStr(mStat) + ' - A SEFAZ bloqueará a consulta por 1h');
          BloqueiaBuscaSefaz(0, mStat);
          CarregarCadastro;
          Exit;
        end;

      if (mMaxNSUNFe.ToInteger > mUltNSUNFe.ToInteger) then
        begin
          PanelStatus('Aguardando retorno da SEFAZ');
          Sleep(30000);
          ACBrNFeStatusChange(nil);
        end;
    until mMaxNSUNFe = mUltNSUNFe;

/***************************************************************************************************************/

 

Porém, para NFe, não estamos conseguindo chegar a uma solução.

Estamos com os fontes do ACBr atualizados, conferi os novos links e já estão OK.

 

Conferi as alterações na NT e também já procurei em diversos tópicos para ver se alguém está tendo problemas parecidos.

 

/***************************************************************************************************************/

Agora, o problema:

Estou realizando a busca(aguardados 60 minutos da consulta anterior) com o ultNSU retornado na última busca.

image.thumb.png.1409b9e8c8fa413f6efb2224a4fed8d5.png

O retorno está sempre mostrando que o maxNSU é 0

image.thumb.png.722ad85841c753e75bb24cedc9d18780.png

Visto que o maxNSU é o maior NSU disponível para consulta, faria sentido ser 0 caso não houvesse mais nenhum NSU para ser retornado, porém, esse cliente está a semanas sem que retorne nota alguma e cada vez mais está acontecendo este mesmo problema em outros clientes.

Revisei todo o código acima apresentado, pesquisei em diversos sites(inclusive alguns tópicos aqui anexados), li as últimas NTs (mais de uma vez) tentando encontrar onde estamos pecando, mas não consegui identificar.

É a primeira vez que posto algo aqui, então caso falte alguma informação para que possam me ajudar, peço desculpas e as inserirei assim que solicitada.

Caso alguém tenha alguma ideia do que eu poderia estar tentando fazer para resolver o problema e também caso possam esclarecer se é melhor deixar em processo automático essa busca de documentos ou manter como fazemos hoje onde o usuário pode fazer a consulta quando precisar(respeitando os bloqueios para evitar o consumo indevido).

 

Apenas para ilustrar, acabei de fazer uma consulta nesse exato momento.

image.thumb.png.e271ffd66c390e875264c2bd1af115cd.png

image.thumb.png.e94386346830b4b0e7150c893e403fe5.png

  • Consultores
  • Solution
Postado

Boa tarde,

Quando ocorre o consumo indevido, agora a Sefaz devolve o último NSU junto da rejeição.

O maxNSU virá corretamente quando não houver rejeição.

Como você está aguardando o mínimo recomendado é muito provável que outro sistema esteja consumindo o serviço para o mesmo CNPJ, talvez a contabilidade, gerando o consumo indevido.

Isso tem sido um constante relato das outras pessoas.

  • Obrigado 1
Postado

Acho que não é essa a questão. Estou com o mesmo problema.

O fato é que a "DistribuicaoDFePorUltNSU" gera esse erro em todas as situações e por exemplo essa função "DistribuicaoDFePorNSU" não gera. 

Ela executa e baixa normalmente as requisições, infelizmente ela acaba bloqueando por exceder as 20 requisições por hora.

Acredito que seja um bug nessa função "DistribuicaoDFePorUltNSU"

Estou trabalhando com essa função "DistribuicaoDFePorNSU" por hora informado aos clientes que logo iremos resolver. 

  • Obrigado 1
  • Moderadores
Postado

No DistribuicaoDFePorUltNSU, quando você recebe o cStat 137, deve aguardar pelo menos 1h pra fazer nova chamada, caso contrário vai receber essa rejeição.

Se a aplicação aguardou 1h e mesmo assim recebeu a rejeição, uma possibilidade é ter outra aplicação da própria empresa ou de alguém usando o certificado da empresa, como o contador, por exemplo, fazendo a mesma consulta.

No DistribuicaoDFePorNSU não existe essa validação, mas existe o limite de 20 consultas por hora, assim como no DistribuicaoDFePorChaveNFe.

  • Obrigado 1
Equipe ACBr BigWings
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

 

 

Postado

@roclopescgmail Fiz um novo teste, dessa vez consultando por DistribuicaoDFePorNSU como você mencionou, após dias, veio uma nota.

Vou adicionar alguns tratamentos para evitar o consumo indevido, mas parece que por hora, essa solução irá resolver uma parte de nossos problemas, porém, a consulta acabará ficando lenta, logo, será uma solução paliativa.

 

image.thumb.png.f371ba0394b59434e156da87ffc43718.png

21 minutos atrás, BigWings disse:

No DistribuicaoDFePorUltNSU, quando você recebe o cStat 137, deve aguardar pelo menos 1h pra fazer nova chamada, caso contrário vai receber essa rejeição.

Se a aplicação aguardou 1h e mesmo assim recebeu a rejeição, uma possibilidade é ter outra aplicação da própria empresa ou de alguém usando o certificado da empresa, como o contador, por exemplo, fazendo a mesma consulta.

No DistribuicaoDFePorNSU não existe essa validação, mas existe o limite de 20 consultas por hora, assim como no DistribuicaoDFePorChaveNFe.

Certo, irei fazer os tratamentos conforme normativas.

Postado

Não creio que seja esse o caso, pois tenho utilizado a mesma rotina tanto no sistema da nossa empresa como em clientes da nossa automação, e idenpendente

do tempo em que a consulta é realizada ele apresenta a mensagem de bloqueio, seja de dia ou de madrugada.

Enfim, espero ter uma solução para essa questão, pois no caso dos meus clientes, ele são de pequeno porte, e essa implementação resolve por hora,

mas aqui para o meu negócio fica um pouco mais complicado.

Mas o fato mais importante é que funcionada antes com a função citada, depois de alguma atualização ele parou.

 

"No DistribuicaoDFePorUltNSU, quando você recebe o cStat 137, deve aguardar pelo menos 1h pra fazer nova chamada, caso contrário vai receber essa rejeição.

Se a aplicação aguardou 1h e mesmo assim recebeu a rejeição, uma possibilidade é ter outra aplicação da própria empresa ou de alguém usando o certificado da empresa, como o contador, por exemplo, fazendo a mesma consulta.

No DistribuicaoDFePorNSU não existe essa validação, mas existe o limite de 20 consultas por hora, assim como no DistribuicaoDFePorChaveNFe."

  • Curtir 1
Postado
Em 14/06/2022 at 09:08, roclopescgmail disse:

Acho que não é essa a questão. Estou com o mesmo problema.

O fato é que a "DistribuicaoDFePorUltNSU" gera esse erro em todas as situações e por exemplo essa função "DistribuicaoDFePorNSU" não gera. 

Ela executa e baixa normalmente as requisições, infelizmente ela acaba bloqueando por exceder as 20 requisições por hora.

Acredito que seja um bug nessa função "DistribuicaoDFePorUltNSU"

Estou trabalhando com essa função "DistribuicaoDFePorNSU" por hora informado aos clientes que logo iremos resolver. 

@roclopescgmail Desde quarta feira venho acompanhando o fluxo das notas, o cliente em questão possui um fluxo bem pequeno de notas, desde que alterei os métodos para usar o DistribuicaoDFePorNSU como você mencionou, estamos conseguindo buscar as notas sem problemas.

Coloquei abaixo os logs que gravei no banco referente as requisições que fizemos, enquanto usado DistribuicaoDFePorUltNSU(Grifado em vermelho) a primeira consulta, independente de tempo de espera, resulta sempre em consumo indevido,

depois comecei a testar DistribuicaoDFePorNSU(Grifado em azul) e começou a trazer notas, posteriormente fiz alguns tratamentos para buscar de tempos em tempos(Grifado em roxo), 

image.thumb.png.c999033c3848147f79e1b74de875d03b.png

 

Essas notas não possuem nenhum evento de manifestação, então, parece que realmente não tem ninguém utilizando o certificado(ou pelo menos, não estão manifestando), mesmo assim, toda consulta por DistribuicaoDFePorUltNSU resultava em consumo indevido.

image.thumb.png.55615b1320b2e2b7a8409f3380d6c7d8.png

 

Por hora, muito obrigado @roclopescgmail.

Obrigado @Renato Rubinho e @BigWings pelas orientações.

  • Curtir 1
  • Este tópico foi criado há 892 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.
Visitante
Este tópico está agora fechado para novas respostas
×
×
  • 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.

The popup will be closed in 10 segundos...