NFSe trunk2 thema.ini

[Cristiane - Afirmação]

Ítalo,

Depois de tantos testes, voltamos à estaca zero.
E volta a velha pergunta: por que no Trunk1 era instantâneo e no Trunk2 leva em média 2 minutos para conseguirmos pegar um retorno?

Editado 5 Maio, 2016 por Cristiane - Afirmação

[Tailon Edson]

Bom dia.

Esse problema é bem pertinente...
Eu passei alguns dias debugando todo o fonte da NFSe, ponta a ponta, e a parte que gera a grande lentidão é aquele trecho que já foi citado nas primeiras paginas do tópico.
Não tem muita lógica ela ser lenta, até porque é praticamente idêntica ao do Trunk1, e lá é muito rápido.

Desculpe qualquer ingenuidade no assunto, mas por acaso o Trunk2 utiliza de outras bibliotecas de SSL ou Capicom? Digo, dlls diferentes da do trunk1? 
Alem desses ajuste notáveis em código, foi atualizado alguma outra coisa referente a comunicação?

O que eu fiz aqui na empresa para solucionar logo na época foi modular o sistema, separamos NFe, NFSe, CTe, MDFe em modulos de DLLs, do qual cada um é compilado separadamente, assim podemos ter versões de ACBr diferentes rodando, sem gambiarras de código juntando Trunk1 e Trunk2, e o Modulo de NFSe nós usamos o Trunk1, que é funcional.
 

[SISVALE SISTEMAS]

Bom Dia Pessoal.
Fiz alguns testes conforme posts anteriores, tentei com várias combinações nos temporizadores, debugando passo-a-passo,  mas também continuo na mesma, idem a Cristiane acima. Mas vou continuar analisando, se descobrir algo post aqui.
Uma dúvida: Será que essa demora não tem a ver com DNS de nosso provedor de internet?

Editado 5 Maio, 2016 por DOCFABIO

[Cristiane - Afirmação]

DOCFABIO,

A princípio, DNS de nosso provedor não faz sentido, pois Trunk1 funciona com rapidez, utilizando a mesma estrutura.

[Italo Giurizzato Junior]

Bom dia a todos,

Que eu saiba as DLLs do Capicom e OpenSSL continuam as mesmas.

Acredito ter encontrado o problema, no Trunk o componente alterava o SoapAction quando a quantidade de RPS era menor que 4, já no Trunk2 estava usando sempre o mesmo SoapAction.

Fiz uma alteração visando realizar a troca dependendo da quantidade de RPS.

Por favor atualizem os fontes e façam novos testes.

[Cristiane - Afirmação]

Vamos soltar foguetes, Ítalo!

O tempo reduziu para 8 a 10 segundos! Isto que deixei a primeira consulta com 5 segundos, as outras de 1 em 1...

Ótimo!!!

[Italo Giurizzato Junior]

Cristiane,

Maravilha, peço desculpas em não atentar sobre o fato do SoapAction ser diferente dependendo da quantidade de RPS no Lote.

Por outro lado agradeço pelos seus testes.

Acredito que os demais que estavam com o mesmo problema agora vai ficar mais rápido.

[Cristiane - Afirmação]

NFS-e de Rondonópolis/MT, provedor Ábaco, funcionando! Testado e hoje será colocado em produção no cliente.

[Italo Giurizzato Junior]

Boa tarde Cristiane,

Posso então considerar que o provedor Ábaco esta funcionando 100%?

[RafaelSchwan]

Boa tarde pessoal!

Muito obrigado Ítalo, Provedor Thema para Lajeado/RS funcionando perfeitamente agora.

Editado 5 Maio, 2016 por RafaelSchwan

[Cristiane - Afirmação]

Sim, Ítalo! Pode considerar funcionando o provedor Ábaco.

[st.marcelo]

Bom dia,

   Com a Thema em Venâncio Aires, mesmo fazendo todas as configurações informadas, a consulta não está retornando nenhuma NF.  Alguém alguma ideia do que pode estar impedindo a consulta?

Estou usando o trunk2, já fiz testes utilizando ou não o Certificado;

 ACBR_NFSE_Configura; (Faz as configurações do componente.)

 ACBrNFSe1.NotasFiscais.Clear;
 ACBrNFSe1.NotasFiscais.LoadFromFile(cdsNotast_arquivoxml.AsString);
 ACBrNFSe1.ConsultarNFSeporRps(ACBrNFSe1.NotasFiscais.Items[0].NFSe.IdentificacaoRps.Numero,
                                ACBrNFSe1.NotasFiscais.Items[0].NFSe.IdentificacaoRps.Serie,
                                TipoRPSToStr(ACBrNFSe1.NotasFiscais.Items[0].NFSe.IdentificacaoRps.Tipo));

 

 

 

[SISVALE SISTEMAS]

Bom Dia Pessoal.

Só ontem consegui atualizar tudo e realizar os testes.

Aparentemente está perfeito  Obrigado italo.

st.marcelo - o comando que uso é exatamente igual ao seu e não acontece esse erro.