Ir para conteúdo
  • Cadastre-se

dev botao

Apos tentar Transmitir o NFCe retorna , Erro Interno: 10060 Erro HTTP: 0


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

Recommended Posts

  • Membros Pro

Bom Dia

Apos executar os comandos abaixo , ele retorna o erro informado , abaixo esta toda sequencia do ACBR de comando e no final o erro , o grande problema para localizar e que esta intermitente , não da erro todo tempo , a cada 5 vendas 2 da erro.

NFe.SetVersaoDF("3.10")
OK: 
NFe.SetModeloDF(65)
OK: 
Configuração geral gravada com sucesso
Configuração de Boletos gravada com sucesso
Dados da Sw.House gravados com sucesso
NFe.SetIDToken(000001)
OK: 
Configuração geral gravada com sucesso
Configuração de Boletos gravada com sucesso
Dados da Sw.House gravados com sucesso
NFe.SetToken(A1EA2953-0843-8F7D-ECFF-475C8781BE9B)
OK: 
NFe.SetModeloDF(65)
OK: 
NFe.CriarEnviarNFe("[Identificacao]
NaturezaOperacao=VENDA
FormaPag=2
Modelo=65
Codigo=008768
Numero=008768
Emissao=30/09/2015 10:49:27
Saida=30/09/2015
tpImp=4
tpemis=1
indPres=1
Finalidade=1
TpAmb=1
procEmi=0
CidadeCod=2507507
indFinal=1
[infNFe]
versao=3.10
[Emitente]
CNPJ=12935052000309
IE=161315348              
Razao=J.S.TECIDOS LTDA - Filial I
Fantasia=VERONA LAGOA
CRT=3
Fone=32224994                   
CEP=58013150
Logradouro=RUA SANTO ELIAS                         
Numero=261       
Cidade=JOAO PESSOA                             
UF=PB
Bairro=CENTRO                                  
CidadeCod=2507507
[Produto001]
CFOP=5102
Item=1
Codigo=089891
Descricao=FRIGIDEIRA BIS 20 0.039                      
NCM=76151900
EAN=1000000898910       
Unidade=UNIDA
Quantidade=1.000
ValorUnitario=32.99
ValorTotal=32.99
ValorDesconto=0.00
IndTot=1
vTotTrib=32.99
[ICMS001]
Origem=0
CST=000
vICMSDeson=5.61
vICMSOp=5.61
pDif=0.00
vICMSDif=0.00
[Produto002]
CFOP=5102
Item=2
Codigo=005775
Descricao=GARRAFA TERM GLT 1LT PRETA 8311              
NCM=96170010
EAN=7891691183119       
Unidade=PECA 
Quantidade=1.000
ValorUnitario=18.90
ValorTotal=18.90
ValorDesconto=0.00
IndTot=1
vTotTrib=18.90
[ICMS002]
Origem=0
CST=000
vICMSDeson=3.21
vICMSOp=3.21
pDif=0.00
vICMSDif=0.00
[Produto003]
CFOP=5403
Item=3
Codigo=091547
Descricao=JOGO AMERICANO PLAST AMER-25LI               
NCM=39241000
EAN=7899183908745       
Unidade=PECA 
Quantidade=8.000
ValorUnitario=4.49
ValorTotal=35.92
ValorDesconto=0.00
IndTot=1
vTotTrib=0.00
[ICMS003]
Origem=0
CST=060
vICMSDeson=0.00
vICMSOp=0.00
pDif=0.00
vICMSDif=0.00
[Produto004]
CFOP=5403
Item=4
Codigo=088645
Descricao=LUGAR AMERICANO DAY LINE 43.5X28.2CM         
NCM=39241000
EAN=1000000886450       
Unidade=PECA 
Quantidade=6.000
ValorUnitario=2.99
ValorTotal=17.94
ValorDesconto=0.00
IndTot=1
vTotTrib=0.00
[ICMS004]
Origem=0
CST=060
vICMSDeson=0.00
vICMSOp=0.00
pDif=0.00
vICMSDif=0.00
[Total]
ValorProduto=105.75
ValorDesconto=0.00
ValorNota=105.75
vTotTrib=51.89
[Pag001]
tpag=03
vpag=105.75
[Transportador]
FretePorConta=9
[DadosAdicionais]
Complemento= Vendedor 166 - DJAILMA CRISTINA (F1)"
)
ERRO: 
Erro Interno: 10060
Erro HTTP: 0

Link para o comentário
Compartilhar em outros sites

  • Membros Pro

Usei a solução proposta acima do link , mas de nada adiantou , pra resolver sem causar dor de cabeça no usuario e ligações no suporte estou enviando uma consulta de web service e retorno com o erro , deixo o sistema ignorar o erro , então sempre o proximo envio fica correto , e como se algo estivesse bloqueado que apos ser enviado o webservice fica disponivel , porque no erro antigo se enviar o cupom imediatamente novamente todo processo acontece sem problemas , então fica a dica para quem estiver enfrentanto o mesmo problema.

NFE.StatusServico("")

ERRO: WebService Consulta Status serviço:
- Inativo ou Inoperante tente novamente.
Erro Interno: 10060
Erro HTTP: 0

Editado por Marcio Tullio
Link para o comentário
Compartilhar em outros sites

Bom dia, Marcio.

Também estou enfrentando este problema, só que no meu caso ocorre da seguinte forma:

Envio 3 NF-e na sequência. Aguardo o prazo de tolerância para cancelar as mesmas. Quando vou cancelar ocorre o erro "Erro Interno: 10060 Erro HTTP: 0". Na sequência já clico para cancelar novamente e a operação é concluída. 

Tentei simular este erro no ACBrNFeDemo, no entanto sem sucesso. Tentei seguir as orientações do Daniel, mas confesso que nem o registro " W3Proxy" consegui localizar na minha máquina. De fato não não utilizo Proxy, não sei se é por isso. Mas enfim...

Uma pergunta, esta solução que você esta utilizando, não vai gerar um consumo indevido nos Web Services? Pelo que entendi para cada envio de NFC-e você faz uma consulta e trata o retorno. Não me lembro bem, mas existe uma NT que trata justamente sobre o uso indevido nas consultas.

Obrigado!

Link para o comentário
Compartilhar em outros sites

  • Membros Pro

Sim , foi o metodo POG para liberar o cliente , hoje foi postado uma nova versão do acbrplus so testei em homologação  , mas só consigo testar amanha e postar o resultado sábado , se realmente resolveu , porque no ambiente de produção do cliente e mais propicio a erros pelo volume de dados e variantes desfavoráveis então , vou atualizar e deixar rodando amanhã para ver no que dá , se bem que ate agora não deu excesso de transmissão , ele retornaria o erro e fala a NT que fica bloqueado naquele Ip , por alguns tempo , so não sei quanto tempo não encontrei.

Link para o comentário
Compartilhar em outros sites

  • Membros Pro

Aconteceu em homologação mesmo o erro do timeout , mesmo com a nova versão 
- Inativo ou Inoperante tente novamente.
Erro Interno: 10060
Erro HTTP: 0

então minha solução para não acontecer o erro e arriscar ficar olhando o status , NFE.StatusServico("") , porque o erro e padrão sempre acontece no primeiro comando , falando assim bem burramente , acredito que ele abra o ambiente no primeiro comando e por algum motivo e negado o acesso , então o ambiente ja fica aberto , então quando e enviado o proximo envio , então o processo acontece sem problemas.

Link para o comentário
Compartilhar em outros sites

  • Fundadores

Você usa CAPICOM e A3, correto ?

Ontem promovemos mudanças na maneira como a classe DFeCapicom inicializa a WinAPI... pode ser que resolva esse problema... Por favor teste com a versão em anexo...

 

ACBrMonitor.zip

Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Link para o comentário
Compartilhar em outros sites

  • 1 mês depois ...
  • Membros Pro

Faz Gambiara do verificar o Status se não voce vai ter problemas sempre , no meu caso deixar o sistema mais lento , mas vc consegue fazer com que ele conecte , mesmo quando da erro o proximo comando e o envio dos dados do NFCe então o canal ta aberto e o erro não acontece , então voce deixa o verifica status , sem pegar o retorno dele que fica mais invisivel o erro para o usuario atualmente uso a versão.0.1.11.12 e persiste o mesmo erro.

Link para o comentário
Compartilhar em outros sites

  • 2 semanas depois ...
  • Fundadores
13 horas atrás, Leandro Araújo disse:

Também estamos com o meso problema aqui na empresa, no caso utilizando OpenSSL.

 

Não adianta esse tipo de Post... Se você deseja que investiguemos o problema, deve fornecer informações detalhadas, para que consigamos reproduzi-lo no nosso ambiente de desenvolvimento...

  • Curtir 1
Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Link para o comentário
Compartilhar em outros sites

Boa noite a todos,

 

Após migrar do trunk para trunk2 meu sistema também começou a apresentar este erro (nunca havia acontecido em vários anos).

Cheguei a migrar para Capicom mas não gostei.

Hoje voltei para OpenSLL, troquei as DLLs pelos arquivos que estão no diretório DLLs\OpenSSL\0,9,8,14 e aparentemente resolveu o problema.

Não tive mais nenhum erro HTTP: 0.

 

Espero que também funcione com vocês.

[]'s

Gabriel

Link para o comentário
Compartilhar em outros sites

Boa noite, senhores.

Estou com este problema há quase dois meses. Já utilizo as DLL na versão 0.9.8.14 desde a migração para o truk2. Criei até uma opção no sistema para o cliente reenviar a nota na sequência, já que quando ocorre o erro, a próxima tentativa obtém êxito. Não quis utilizar a sugestão do Marcio Tullio pois fiquei com medo da SEFAZ bloquear o IP para envio da NFe/NFCe. 

Mas é como o Daniel falou, não adianta ficarmos chorando pintangas e não passarmos um passo a passo para que o problema seja investigado. Já perdi um bom tempo enviando NFe/NFCe em modo Debug e não consegui informações que possam ajudar. Acredito que mais cedo ou mais tarde, algum colaborador conseguirá! Acho que este erro seja um caso isolado, pois apenas 4 membros relataram o problema.

No mais, só tenho elogios, o refactoring realizado no trunk2 deixou as operações relacionadas com NFe/NFCe mais rápidas.

Douglas A R Lima

Link para o comentário
Compartilhar em outros sites

Boa tarde a todos,

 

Após mais alguns testes, acredito fortemente que o problema esteja relacionado com a propriedade TACBrNFe.Configuracoes.Certificado.VerificarValidade.

Descobri que quando ela é True meu sistema apresenta erro HTTP 0 mesmo com as DLLs 0.9.8.14.

Modificando seu valor para False, o problema desapareceu.

Hoje tive aproximadamente 200 notas faturadas e nenhum problema.

 

Aproveito para reforçar os elogios feitos pelo Douglas. O ACBr sempre foi um ótimo projeto e me ajudou muito. Ainda estou me adaptando ao trunk2 mas gostei bastante das modificações. Meus agradecimentos a todos os colaboradores que dedicaram seu tempo para torná-lo possível.

 

[]'s

Gabriel

Link para o comentário
Compartilhar em outros sites

Em 11/12/2015 at 17:41, Leandro Araújo disse:

Também estamos com o meso problema aqui na empresa, no caso utilizando OpenSSL.

 

Também estamos com o mesmo problema aqui na empresa, no caso utilizando OpenSSL.

Em 11/12/2015 at 17:41, Leandro Araújo disse:

Também estamos com o meso problema aqui na empresa, no caso utilizando OpenSSL.

 

 

13 minutos atrás, Leandro Araújo disse:

Também estamos com o mesmo problema aqui na empresa, no caso utilizando OpenSSL.

Também estamos com o mesmo problema aqui na empresa, no caso utilizando OpenSSL.*
O problema que ocorre é que ao efetuar o envio de um lote, ocorre o erro: 'Erro Interno: 11001 Erro HTTP: 500'.
Porém ao efetuar uma consulta recebo o retorno da nota autorizada, em alguns casos tenho que fazer mais uma requisição de consulta, pois o mesmo erro as vezes ocorre na consulta e em outros webservices.
É como se algo estivesse bloqueado e dai quando faz mais um requisição desbloqueia. 

Fizemos semana passada a migração para o trunk2 do ACBr, deixando as mesmas configurações de webservice, timeout etc, não sei se tem a ver, porque clientes nossos que possuem o aplicativo compilado com o 'ACBr1' relataram o mesmo problema, então creio que não seja algo diretamente relacionado ao componente, porém esse erro não está nos afetando tanto pois o sistema possui um mecanismo para permitir gerar novamente uma nota somente se a mesma não foi de fato autorizada, enquanto isso o usuário só pode realizar a consulta, não fazer alterações entre outras coisas.
Vamos realizar testes com Capicom também.
Obrigado.

Leandro Araújo, Analista de Sistemas.

Link para o comentário
Compartilhar em outros sites

Em 12/12/2015 at 07:43, Daniel Simoes disse:

Não adianta esse tipo de Post... Se você deseja que investiguemos o problema, deve fornecer informações detalhadas, para que consigamos reproduzi-lo no nosso ambiente de desenvolvimento...

Desculpe Daniel, é que acabei digitando o inicio do post e postei.
Não se repetirá.
Obrigado.

17 minutos atrás, Leandro Araújo disse:

Também estamos com o mesmo problema aqui na empresa, no caso utilizando OpenSSL.

 

Também estamos com o mesmo problema aqui na empresa, no caso utilizando OpenSSL.*
O problema que ocorre é que ao efetuar o envio de um lote, ocorre o erro: 'Erro Interno: 11001 Erro HTTP: 500'.
Porém ao efetuar uma consulta recebo o retorno da nota autorizada, em alguns casos tenho que fazer mais uma requisição de consulta, pois o mesmo erro as vezes ocorre na consulta e em outros webservices.
É como se algo estivesse bloqueado e dai quando faz mais um requisição desbloqueia. 

Fizemos semana passada a migração para o trunk2 do ACBr, deixando as mesmas configurações de webservice, timeout etc, não sei se tem a ver, porque clientes nossos que possuem o aplicativo compilado com o 'ACBr1' relataram o mesmo problema, então creio que não seja algo diretamente relacionado ao componente, porém esse erro não está nos afetando tanto pois o sistema possui um mecanismo para permitir gerar novamente uma nota somente se a mesma não foi de fato autorizada, enquanto isso o usuário só pode realizar a consulta, não fazer alterações entre outras coisas.
Vamos realizar testes com Capicom também.
Obrigado.

Corrigindo: 
Erro Interno: 10060
Erro HTTP: 0

Leandro Araújo, Analista de Sistemas.

Link para o comentário
Compartilhar em outros sites

Realmente, esse erro parece ser de tempo limite estourado.
Verifiquei a seguinte descrição no arquivo '...\ACBr\Fontes\Terceiros\synalist\blcksock.pas' na linha 3209-3210 que é um erro de timeout.

WSAETIMEDOUT: {10060}
      Result := 'Connection timed out';

Vou experimentar aumentar ainda mais os intervalos entre as tentativas para ver o que acontece.

Obrigado.

Leandro Araújo, Analista de Sistemas.

Link para o comentário
Compartilhar em outros sites

  • Membros Pro

Bem , ja existe esse parametro criado no ACBR para o timeout e não resolve em nada , desculpe talvez ser leigo agora , mas vou dizer besteria ,  e como se houve-se um LOGIN não completado , sempre que uso  NFE.StatusServico("")  , em toda NF a ser transmitida em alguns casos ele da erro e o erro e muito variante , as vezes passa dias sem acontecer e tem dias que a cada venda acontece , então , quando vem o retorno com o erro eu ignoro , mas o proximo envio sempre da certo.

Quanto ao limite e block de ip nunca sofri deste problema e não encontrei a regra que diz a quantidade , so li que pode acontecer.

Link para o comentário
Compartilhar em outros sites

  • 3 semanas depois ...
16 horas atrás, Leandro Araújo disse:

Alguém já conseguiu resolver esse erro, sem ter que fazer alguma alteração?
Obrigado.

Experimentei trocar a dll 'ssleay32' da versão '0.9.8.14' para a versão '1.0.2.1', mas sem sucesso, porém o erro mudou para 'Erro interno: 10091 Erro HTTP: 500'.

Editado por Leandro Araújo

Leandro Araújo, Analista de Sistemas.

Link para o comentário
Compartilhar em outros sites

6 horas atrás, Leandro Araújo disse:

Experimentei trocar a dll 'ssleay32' da versão '0.9.8.14' para a versão '1.0.2.1', mas sem sucesso, porém o erro mudou para 'Erro interno: 10091 Erro HTTP: 500'.

Voltei as DLLs da versão '0.9.8.14', mas o erro interno 10060 Erro HTTP: 0 persiste em mais de um cliente. Já foram alteradas configurações de timeout e nada.

Editado por Leandro Araújo

Leandro Araújo, Analista de Sistemas.

Link para o comentário
Compartilhar em outros sites

Boa tarde, Leandro.

Estes clientes que persistem com o erro 10060 utilizam certificado A1? Caso sim, faça o seguinte teste, instale o certificado no IE e configure o mesmo na opção CAPICOM. No meu caso este erro ocorre somente quando informo o caminho do arquivo "pfx". Depois que instalei no IE, parou de ocorrer o erro.

 

  • Curtir 1
Link para o comentário
Compartilhar em outros sites

57 minutos atrás, douglasarlima disse:

Boa tarde, Leandro.

Estes clientes que persistem com o erro 10060 utilizam certificado A1? Caso sim, faça o seguinte teste, instale o certificado no IE e configure o mesmo na opção CAPICOM. No meu caso este erro ocorre somente quando informo o caminho do arquivo "pfx". Depois que instalei no IE, parou de ocorrer o erro.

 

Boa tarde.
Sim, é A1, e estamos utilizando com OpenSSL, e este erro HTTP está ocorrendo.
Muitos de nossos clientes utilizam a aplicação via acesso remoto, rodando no Windows Server 2008, o motivo de utilizarmos OpenSSL nesse caso é um antigo problema de "crashes" (telas brancas) com o nosso aplicativo na versão Capicom nesse sistema operacional.
Veja o tópico: http://www.projetoacbr.com.br/forum/topic/11467-msxml5dll-windows-x64/?do=findComment&comment=112857
Porém não sei se o mesmo já foi corrigido.
Os nossos únicos clientes que utilizam Capicom são os que possuem certificados A3 mesmo, os quais OpenSSL não suporta.
Observei esse erro HTTP após migrar para o trunk2, já tentei trocar a dll 'ssleay32' e aumentar os timeouts, mas não resolveu.

Observação: O erro ocorre com pouca frequência em ambiente de homologação, porém em produção é notável.

Obrigado.

Editado por Leandro Araújo
Erro no texto

Leandro Araújo, Analista de Sistemas.

Link para o comentário
Compartilhar em outros sites

  • Este tópico foi criado há 2544 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Crie uma conta ou entre para comentar

Você precisar ser um membro para fazer um comentário

Criar uma conta

Crie uma nova conta em nossa comunidade. É fácil!

Crie uma nova conta

Entrar

Já tem uma conta? Faça o login.

Entrar Agora
×
×
  • 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.