12002 - TimeOut de Requisição

[johnbh3]

Pessoal
Estou com uma situação estranha!

Eu tenho pra mim que e o provedor da NFSe de Sabara (ISS Digital)
Até 3 dias atrás estava tudo normal. 

Erro Interno: 12002
Erro HTTP: 0
Falha Recebendo Dados. Erro:Erro: 12002 - TimeOut de Requisição

Consulta situação do lote mesma coisa (As vezes nesta situação da acess violation)
Cancelamento mesma coisa.

No meu PC envia, do meu cliente não envia. Mas os mesmo problemas la acontece aqui. No meu pc ainda um pouco menos no envio, mas em todos outros serviços mesmo erro.
Como ele e do meu lado, até vou levar meu notebook pra testar na internet dele pra verificar se a internet dele ou pc no caso do envio.

Ja ajustei timeout pra 5, 10,15 ate 20 segundos. Esses provedores até fiz contato, mas eles pedem cada coisa ridicula, e por mim diz que esta tudo normal. De forma alguma assumem que tem algum problema. 

Mesmo no meu PC o cancelamento tenho que tentar varias vezes. Até uma hora o envio e retorno acontecer sem problema. Chega ate dizer que já esta cancelado, mas quando isso ocorre e como se o webservice tivesse retornado e para em seguida. A consulta situação do lote de forma alguma funciona. Lembrando senhores, que uso isto a 2 anos em Sabara. Em BH esta super normal, por isso eu creio que seja mesmo o povedor issDigital. So me intrigou mesmo meu enviar e do cliente sequer enviar. 

A velocidade internet pode influenciar? Eu ter 60 megas e eles bem menos? por isso pelo menos isso eu estou conseguindo? 

Editado 24 Abril, 2018 por johnbh3

[johnbh3]

Ola
Ainda com problemas la.
Hora nota aprova hora nao.

Quando tento cancelar 
Sempre me da erro, porem no site consta como cancelada

Tento cancelar novamente
e tento tratar assim
                  if ACBrNFSe1.WebServices.CancNFSe.RetCancNFSe.InfCanc.MsgRetorno[0].Codigo='E79' then

e da erro de acess violation 

Se tentar acessar qualquer tag de RetCancNFSe da erro.

Editado 25 Abril, 2018 por johnbh3

[johnbh3]

Com muito custo eles nos ligaram

 

Agora informando que nome do arquivo não pode ter letras ou traços. Coisa que funcionava a 2 anos. Parou a 2 dias. Tentam de todas as formas fugir do problema

 

[johnbh3]

Prezado JOHN

 

Conforme contato telefônico aguardo retorno para que possamos verificar a situação em questão. 

 

Obs: Caso possível favor nomear os arquivos xml de envio com nome simples (sem espaços , traços)

Exemplo: 897env.xml , rps897.xml  

E não 897-env-lot.xml   

 

E após nomear peço a gentileza de processá-los novamente e verificar se será gerado o protocolo do envio.


O ACBR gera com nome : 905-env-lot.xml 
Alguém usa ISSDigital?

 

Estava funcionando normal. Eles me dizem que isso e motivo, parou do nada. A 2 dias. Até então tudo perfeito.

 

Ate achei este trecho do codigo: 

procedure TNFSeEnviarLoteRPS.Clear;
begin
  inherited Clear;

  FPStatus := stNFSeRecepcao;
  FPLayout := LayNFSeRecepcaoLote;
  FPArqEnv :=  'envlot';//   'env-lot';
  FPArqResp := 'rec';

  FProtocolo := '';

  if Assigned(FRetornoNFSe) then
    FreeAndNil(FRetornoNFSe);
end;

Porem  o arquivo gerou com nome de:  905-envlot.xml (Ainda tem o traço no final do numero do lote) - Sabem onde posso tentar alterar? pra tirar este ultimo traço?

[Italo Giurizzato Junior]

Bom dia John,

O provedor ISSDigital não possui um WebService?

Pelo que estou entendendo você esta gerando o XML de envio de lote e esta importando o seu conteúdo através do site.

Isso confere?

Pois quando o lote é enviado para o provedor via WebService não enviamos o nome do arquivo XML e sim apenas o seu conteúdo.

[johnbh3]

Ola

Bom dia. Sim tem webservice e uso em Sabará a 2 anos. Parou a 2, 3 dias. Assim que clico em enviar o rps já consta no site deles. Da falha no retorno. Eu achei a resposta deles bizarra dizendo ser o nome do arquivo. Porque o rps e enviado. Falha e no retorno, então que influencia o nome do arquivo tem se a falha e no retorno(o retorno eles manda o arquivo como quiser). 

 

Já tentei foi de tudo. Nada faz isso funcionar, eu aleguei pra eles. Que hora autoriza, hora não. Hora consulta situação do lote hora não, o cancelamento tente algumas vezes até da rps já cancelado tudo tratado. Não vejo a hora da nfse nacional sair. Porque esses provedores não assumem problema nenhum. Argumentei as questões logicas.

[johnbh3]

Ola
Italo

Eles fizeram um acesso remoto aqui comigo. 
Agora me diz que o arquivo de consulta situação do lote esta em desacordo.

em anexo modelo gerado para consulta do acbr e modelo gerado para por eles. 

Existe uma pequena diferença,além de precisar de ter que informar o protocolo na consulta.
Sabe me dizer se algum provedor tem modelo igual? 

gerado_pelo_acbr_.xml

modelo_do_provedor_.xml

Editado 26 Abril, 2018 por johnbh3

[Italo Giurizzato Junior]

Bom dia John,

Você notou que o XML de consulta gerado pelo ACBr se refere a Consulta a NFS-e por RPS?

E o XML gerado pelo provedor se refere a Consulta ao Lote de RPS.

O ACBrNFSe possui um método para Consultar o Lote de RPS e um dos parâmetros a ser informado é o numero do protocolo.

[johnbh3]

Ola
Italo,
Bom  dia

Eu respondi isto a eles ontem mesmo.
Cara eu estava com a cabeça a mil, tanta raiva que já passei com esse pessoal.

Na hora eles acessaram aqui. Em meio a tentar de tudo, na hora nem notei que ela estava enganada.
Eu tentei as duas da manhã do dia anterior, nem tinha dormido direito. 

Esse provedor sinceramente e um um fumo. Eu sinceramente já estou considerando pedir a rescisão de contrato pra esses clientes. Eu não vejo o porque haver alguma falha no ACBr. Sendo que estava tudo OK, BH por exemplo nunca para, o negocio e foda bom demais. Mas essa ISSDigital tenta fugir do problema de todas as formas. 
A resposta anterior era pra mudar os nomes dos arquivos que não podia ter traços, ai mostrei que a falha estava era no retorno e não no envio.

Mas valeu pela tentativa de ajuda. Mas eu perdi a esperança.

Você tem alguma noção se NFSe Nacional vai mesmo sair?
 

 

Editado 27 Abril, 2018 por johnbh3

[Italo Giurizzato Junior]

John,

Sim, a NFS-e Padrão Nacional esta saindo do papel e vai se tornar realidade em breve.

É claro que uma prefeitura que acabou de assinar o contrato com um  provedor vai ter que esperar terminar esse contrato que pode levar ai uns 4 anos.

[johnbh3]

Ola
Italo!

Boa noite.
Cara!
Coisa estranha, o provedor não esta com problema nenhum mesmo. Eu voltei o cliente pra uma versão anterior e esta funcionamento normalmente. Isso começou aconteceu apos ter atualizado o ACBR em Janeiro/2018 para mecher com a NFe 4.0. E isso fez com que a NFSe pare de funcionar pra este provedor especificamente.

Ate tentei copiar os arquivos do acbr que eu usei nesta versão Fontes\ACBrDFe\ACBrNFSe e colei na nova pasta que estou usando utilizando atuamente com Acbr Atualizado. 

Mas continua com mesmo erro. Se voltar pra versão anterior nada acontece. Então tem algo modificado pra este provedor, nesta atualização do ACBR que eu fiz. Eu recompelei com ACBR novo de hoje e mesmo erro de time out de requisição.

 

 

[Italo Giurizzato Junior]

Bom dia John,

Neste caso é preciso comparar os fontes do componente, o atual com o que funciona para ver o que foi alterado.

[johnbh3]

Você tem ideia de qual unit especificaente preciso olhar?
Uma vez que o problema esta no retorno, e especificamente deste provedor. BHISS funciona normal.

Isto parece ser problema relacionado com isso

      ACBrNFSe1.Configuracoes.Geral.SSLLib         := libWinCrypt; //ja tentei com capicom
      ACBrNFSe1.Configuracoes.Geral.SSLCryptLib    :=cryWinCrypt;
      ACBrNFSe1.Configuracoes.Geral.SSLHttpLib     :=httpWinHttp;
      ACBrNFSe1.Configuracoes.Geral.SSLXmlSignLib  := xsMsXml;

 

 ACBrNFSe1.SSL.SSLType :=LT_TLSv1_2; // Já tentei todas opções desta propriedade

 

A unica certeza que tenho que  não e o provedor mesmo com problema. Até então achei que era com eles. 

Você tem ideia de qual unit especificaente preciso olhar?
Uma vez que o problema esta no retorno, e especificamente deste provedor. BHISS funciona normal.

Isto parece ser problema relacionado com isso

      ACBrNFSe1.Configuracoes.Geral.SSLLib         := libWinCrypt; //ja tentei com capicom
      ACBrNFSe1.Configuracoes.Geral.SSLCryptLib    :=cryWinCrypt;
      ACBrNFSe1.Configuracoes.Geral.SSLHttpLib     :=httpWinHttp;
      ACBrNFSe1.Configuracoes.Geral.SSLXmlSignLib  := xsMsXml;

 

 ACBrNFSe1.SSL.SSLType :=LT_TLSv1_2; // Já tentei todas opções desta propriedade

 

A unica certeza que tenho que  não e o provedor mesmo com problema. Até então achei que era com eles

[eciello]

No provedor TECNOS, também estou recebendo esta mensagem de erro, após atualização das fontes para testes da NFe 4.00

Erro Interno: 12002
Erro HTTP: 0
Erro: Requisição não enviada.
Erro: 12002 - TimeOut de Requisição

[johnbh3]

Ola
Amigo 

Tente fazer isso : ACBrNFSe1.Configuracoes.WebServices.TimeOut := 15000;

[eciello]

John, bom dia, você conseguiu resolver o seu problema ? percebi que a minha situação é bem parecida, a NFSe é recebida pelo provedor,

e fica OK, mas neste intervalo do retorno é gerado o erro de TimeOut, eu uso as seguinte configurações :

NFSe1.Configuracoes.WebServices.TimeOut := 15000;
NFSe1.Configuracoes.WebServices.AguardarConsultaRet := 5000;
NFSe1.Configuracoes.WebServices.IntervaloTentativas := 3000;
NFSe1.Configuracoes.WebServices.Tentativas := 10;   
NFSe1.Configuracoes.WebServices.AjustaAguardaConsultaRet := True;

[Italo Giurizzato Junior]

Bom dia a todos,

Tentaram atribuir o valor xsLibXml2 a propriedade SSLXmlSignLib?

[Diego Paulo Sabino]

Bom dia a todos,

Eu consegui resolver o problema para a cidade de Cabo Frio. 

Como já foi falado acima, na versão antiga do Acbr funcionava perfeitamente, porém na nova não, ae mexendo nos parâmetros eu mudei o local onde envio SENHA E FRASE SECRETA. Funcionou perfeitamente!

Local correto:

ACBrNFSe1.Configuracoes.Geral.Emitente.WebSenha := SEnha
ACBrNFSe1.Configuracoes.Geral.Emitente.WebFraseSecr := Frase

De qualquer forma, tiveram mudanças no arquivo IssDigital.ini com relação ao que está no repositório. Foi anexá-lo para caso queiram atualizá-lo.

 

Muito obrigado pela ajuda!

ISSDigital.ini

[eciello]

1 hora atrás, Italo Jurisato Junior disse:

Bom dia a todos,

Tentaram atribuir o valor xsLibXml2 a propriedade SSLXmlSignLib?

Italo, com a sua dica para o TECNOS, devolve a seguinte mensagem :

Erro na geracao da assinatura!Assinatura invalida. A Assinatura da nota nao confere com a informacao contida no XML.
Verifique as informacoes do seu Certificado Digital

 

[Italo Giurizzato Junior]

Bom dia a todos,

Diego, muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Eciello, o que não ficou claro para mim é o envio ocorre mas o retorno não vem, é isso?

 

[johnbh3]

Ola
Italo

Aproveitando o gancho!
Eu tinha sugerido isso a algum tempo:
Foi desfeito tudo para o mesmo provedor.

Foi comentado algo; estranhamente, pro mesmo provedor parece que em Cidade diferente tem comportamento diferente. 
Essa linha que comentei acima e coloquei
      proISSDigital:
        Gerador.wGrupoNFSe('Rps ' + FIdentificador + '="' + OnlyNumber(FNFSe.IdentificacaoRps.Numero) + '"');

Se nao colocar ela, da erro sempre que lote já foi informado. 


 

pnfsNFSeG.pas

pnfsNFSeW_ABRASFv2.pas

Editado 4 Maio, 2018 por johnbh3

[eciello]

2 horas atrás, Italo Jurisato Junior disse:

Bom dia a todos,

Diego, muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Eciello, o que não ficou claro para mim é o envio ocorre mas o retorno não vem, é isso?

 

Italo, bom dia,

é isso mesmo que ocorre, a NFSe é enviada para o provedor e autorizada, o erro é devolvido durante a execução da função

EnviarSincrono, após com a função ConsultarLoteRps eu consigo fazer a consulta da NFSe.

[Italo Giurizzato Junior]

Boa tarde a todos,

John, vou analisar a sua colaboração, caso esteja tudo ok enviarei para o repositório.

Eciello, pelo que entendi, você envia o RPS, este é recebido pelo webservice que processa com sucesso, mas o provedor demora em dar resposta e acaba ocorrendo erro, correto?

Mas depois ao executar o método ConsultarLoteRPS você obtém o XML da NFS-e, correto?

Bom, acrescentei no método EnviarSincrono um sleep entre o envio e a consulta.

Ele vai tomar como base o tempo informado na propriedade de configuração: AguardarConsultaRet

Vou enviar essa alteração para o repositório, favor atualizar os fontes e faça novos testes.

[eciello]

Em 04/05/2018 at 16:42, Italo Jurisato Junior disse:

Boa tarde a todos,

John, vou analisar a sua colaboração, caso esteja tudo ok enviarei para o repositório.

Eciello, pelo que entendi, você envia o RPS, este é recebido pelo webservice que processa com sucesso, mas o provedor demora em dar resposta e acaba ocorrendo erro, correto?

Mas depois ao executar o método ConsultarLoteRPS você obtém o XML da NFS-e, correto?

Bom, acrescentei no método EnviarSincrono um sleep entre o envio e a consulta.

Ele vai tomar como base o tempo informado na propriedade de configuração: AguardarConsultaRet

Vou enviar essa alteração para o repositório, favor atualizar os fontes e faça novos testes.

Italo, bom dia,

testei sua alteração, não funcionou, pois o erro acontece antes da consulta, mais especificamente :

procedimento - procedure TACBrWinINetReqResp.Execute(Resp: TStream);
 função - HttpSendRequest(fRequest, nil, 0, Pointer(Data), Length(Data))

Meus testes eram em homologação, resolvi testar em produção e esta funcionando corretamente,

agradeço pela sua atenção.

[Italo Giurizzato Junior]

Bom dia eciello,

Se no ambiente de produção esta funcionando corretamente e no de homologação não, podemos concluir o que?

O problema é no provedor, correto?