NFSe trunk2 thema.ini

[Italo Giurizzato Junior]

Bom dia Cristiane,

Favor atualizar os fontes e testar novamente.

[Cristiane - Afirmação]

Agora sim! Ibirubá/RS, pela Digifred, funcionando.

Segunda-feira vai para produção.

[Cristiane - Afirmação]

Ontem eu resolvi atualizar a minha pasta ACBR. Cheguei a excluir todos os arquivos, baixei de novo e compilei tudo de novo.

Está apresentando erro de compilação no

ACBREad.pas

procedure TACBrEAD.LerChaveModuloExpoente(Modulo, Expoente: AnsiString);

Na linha 496:

  RSAKey.e := bnMod;
  RSAKey.d := bnExp;

O que precisa ser feito?

[WINDEL]

Olá, e a questão na velocidade de Aprovação / Consulta da NFse alguém conseguiu melhorar para o provedor Thema? 

Eu estou enviando para Passo Fundo e demora 90 segundos para aprovar, meu cliente tá ficando louco.. hehe

Alguém já achou alguma solução? por que se eu diminuir o intervalo de tentativos e tempo de consulta dá erro que o rps ainda não virou nfse =/

Obrigado por enquanto.

[j2c9m7]

Em 01/04/2016 at 16:56, DIOGOWAR disse:

Olá, e a questão na velocidade de Aprovação / Consulta da NFse alguém conseguiu melhorar para o provedor Thema? 

Eu estou enviando para Passo Fundo e demora 90 segundos para aprovar, meu cliente tá ficando louco.. hehe

Alguém já achou alguma solução? por que se eu diminuir o intervalo de tentativos e tempo de consulta dá erro que o rps ainda não virou nfse =/

Obrigado por enquanto.

Diogowar

Aqui, estou com o aplicativo usando ainda o trunk (leva 2 segundos); pra contornar esse problema da demora com o trunk2, infelizmente eh isso ai, 90 segundos ou mais, e nao consegui descobrir porque, se nao mudou nada? o provedor eh o mesmo, o servidor eh o mesmo, a forma de envio tambem!?

Se alguem tiver uma solucao, favor reportar!

Abraços

[SISVALE SISTEMAS]

Boa Tarde Pessoal.

Aqui também, idem aos 2 post acima do  Diogowar e Jair.
Dificilmente aprova em menos de 30 segundos, a maioria demora mais que 1 minuto.
Deixei trunk2 só com quem usa pouco, 1 nfse por dia.
Mas os que fazem várias nfse por dia tenho ainda que deixar o trunk1 pois faz várias nfse seguidas todas instantâneas.
Debuguei de várias maneiras, principalmente comparando com o trunk1, mas claro o miolo está muito diferente, está dificil descobrir o porque da demora, ainda mais que é intermitente.
No provedor Bhiss tinha o mesmo problema, mas foi resolvido, pois ele tem chamadas que funcionam melhor e que no Thema não tem.
Vide meu último post, na página 4 deste tópico, continua da mesma forma. 

[locodosul]

Nfs-e de Cachoeirinha (Thema) usando a versão Trunk1 demorava em torno de 3 a 10 segundos. Compilando com a última versão do Trunk2 demora de 60 a 120 segundos.

Alguém conseguiu resolver isso?

[Italo Giurizzato Junior]

Boa tarde,

Verifique as configurações de tempo de espera entre uma consulta e outra, bem como o tempo de espera antes de realizar a primeira consulta.

[SISVALE SISTEMAS]

Bom Dia Italo.

Aqui ainda continua na mesma, demorando muito.
Alteramos os temporizadores, autoriza tudo certinho, porem só conseguimos com cerca de 1 minuto entre cada autorização.
Mais informações na página 4 deste.

[RafaelSchwan]

Bom dia, estou com o mesmo problema para Thema, em Lajeado. Já setei os temporizadores conforme solicitado mas o Trunk gera a nota instantaneamente e Trunk2 de 1 a 4 minutos.

Att.

[Italo Giurizzato Junior]

Bom dia Rafael,

Ao enviar o Lote o provedor retorna instantaneamente o numero do protocolo, indicando que recebeu o lote, correto?

O problema ocorre ao consultar a situação do lote?

Que só retorna que o lote foi processado com sucesso depois de 1 minuto ou mais, correto?

Se sim, isso ocorre tanto no ambiente de homologação quando o de produção?

[Cristiane - Afirmação]

Ítalo,

Eu uso o componente configurado para consulta automática. O que demora, sim, é o retorno. E se configurar um tempo menor para a consulta do retorno, ele falha ao trazer o retorno. Acontece tanto em ambiente de homologação quanto de produção.

[Italo Giurizzato Junior]

Boa tarde Cristiane,

A demora no retorno, ocorre na consulta a situação ou a consulta ao lote, ou todos os retornos?

[Cristiane - Afirmação]

Vou testar em separado, aí te falo.

 

[Cristiane - Afirmação]

Configuração do componente:

  ACBrNFSe.Configuracoes.WebServices.AjustaAguardaConsultaRet := True;
  ACBrNFSe.Configuracoes.WebServices.AguardarConsultaRet := 5000;// 5 segundos
  ACBrNFSe.Configuracoes.WebServices.Tentativas := 10;
  ACBrNFSe.Configuracoes.WebServices.IntervaloTentativas := 15 * 1000; // 15 segundos

Depois uso o

ACBRNFSe.Enviar...

Em relação ao retorno do protocolo, é instantâneo. Depois vai fazer a consulta, ai demora quase dois minutos para ter o retorno com o status 4.

O AguardarConsultaRet não faz diferença, 5 segundos, 10 ou 1.

Tentativas, se deixar poucas, corre o risco de não ter retorno.

IntervaloTentativas, o padrão é 15 segundos, aí demora...

Com 10 tentativas e intervalotentativas 5, retorna como lote não processado. Deixando os 15 segundos sempre processa, mas leva aquele tempão que o povo já está reclamando.

[Cristiane - Afirmação]

Quando utilizo os comandos 
ACBRNFSe.ConsultarNfsePorRps
ou
ACBRNFSe.ConsultarNfsePorRps

o retorno é imediato.

Ou ACBRNFSe.ConsultarSituacao o retorno é imediato.

 

[WINDEL]

Mas o retorno é imediato como? retorna que o rps ainda não foi processado ou retorna a nfs-e ?

[Cristiane - Afirmação]

A tela de retorno do protocolo é quase que instantânea. Mas como o componente está configurado para pegar o retorno de lote, até que este seja processado, aí é que fica lento. É tudo em um comando único.

 

[Tailon Edson]

Indiferente, o retorno da consulta do lote é necessário, até porque é ele quem retorna se a nota foi processada com ou sem erros, sem fazer essa consulta não se tem certeza se a nota foi realmente emitida e salva.

[Italo Giurizzato Junior]

Bom dia a todos,

Lembrem-se que existem a versão 1 e 2 do ABRASF, sendo que os provedores que seguem a versão 2 não tem o web services de consultar a situação do lote.

Sendo assim o fluxo para cada versão é:

Versão 1: Enviar / Consultar a Situação do Lote / Consultar o Lote

O retorno do Enviar é o numero do protocolo que acusa que o lote foi recebido.

O retorno do Consultar a Situação do Lote é o código da situação que pode ser 1 = Lote não recebido, 2 = Lote em processamento, 3 = Lote processado com erros e 4 = Lote processado com sucesso.

O retorno do Consultar o Lote, depende da situação, se for 3 teremos as mensagens de erros, por outro lado se for 4 teremos os XMLs das NFS-e.

Na versão 2, como dito não temos o Consultar a Situação do lote, sendo assim essa informação é retornada ao Consultar o lote, por conta disso teremos também as mensagens de erro caso a situação seja 3 ou os XMLs das NFS-e caso seja 4.

Como disse Tailon, o Consultar NFS-e por RPS é um tiro no escuro pois devemos lançar mão dessa consulta quando temos a certeza que o RPS em questão foi processado com sucesso.

Cristiane, me tire uma duvida, se você configurar o componente para não consultar o lote após o envio e executar separadamente os métodos:

Enviar e ConsultarLote ou ConsultarNFSePorRps

Você já obtêm o XML da NFS-e ou a lista de mensagens de erro em um curto espaço de tempo?

 

[Cristiane - Afirmação]

Se eu deixar 

ACBrNFSe.Configuracoes.WebServices.AjustaAguardaConsultaRet := False;

e não configurar as outras variáveis, o componente gera uma excessão como se o tempo de consulta fosse extrapolado. 

[Cristiane - Afirmação]

Se configurar:

ACBrNFSe.Configuracoes.Geral.ConsultaLoteAposEnvio := False;

O Enviar fica instantâneo.

O ACBRNFSe.ConsultarSituacao demora um pouco, mas não tanto quanto antes, quando era junto no comando Enviar (30 segundos ou 1 minuto).

Testei mais outras vezes, e em algumas notas chega a levar 2 minutos para retornar o ConsultarSituacao.

[Cristiane - Afirmação]

A lentidão está em
unit ACBrNFSeWebServices
function TNFSeConsultarSituacaoLoteRPS.Executar: Boolean;

Mas realmente não faz sentido demorar tanto.

 

[Cristiane - Afirmação]

Testes e mais testes. O problema está no comando Sleep do Delphi??? Debugando vai mais rápido, executando direto demora mais.
Dá para melhorar o tempo (um pouco), trocando o intervalo. Eu usava 15 segundos, com 10 repetições, no máximo.

Troquei para 1 segundo, com 1000 repetições. Aí ganha no último intervalo.

Agora parei os testes.

[Italo Giurizzato Junior]

Bom dia Cristiane,

Vamos a algumas propriedades de configuração:

AguardarConsultaRet => permite definir um tempo em milisegundos entre o Envio e a primeira Consulta (para os provedores que seguem a versão 1 da ABRASF essa consulta é Consultar Situação do Lote, já os que seguem a versão 2 é Consultar Lote).

IntervaloTentativas => permite definir um tempo em milisegundos entre uma Consulta e outra (a consulta aqui se refere a Consultar Situação do Lote).

Tentativas => permite definir a quantidade de consultas que serão realizadas (a consulta aqui se refere a Consultar Situação do Lote).

Temos que tomar cuidado com os tempos informados nas duas primeiras propriedades, pois tive conhecimento de um provedor que esta bloqueando o emitente por uso abusivo, ou seja, assim que envia o lote já realiza a consulta para saber a situação do lote.

Sendo assim é interessante deixarmos um intervalo de tempo de pelo menos uns 2 segundos antes de consultar a situação do lote pela primeira vez e depois uns 3 segundos entre uma tentativa e outra.

Quanto ao numero de tentativas não vejo nenhum problema ser 10 ou mais.

Já a propriedade AjustaAguardaConsultaRet para o componente ACBrNFSe não tem função nenhuma, pois nenhum retorno dos provedores retornam um tempo médio de processamento.

Essa propriedade se torna interessante para quem utiliza o ACBrNFe, ACBrCTe, ... pois a SEFAZ retorna o tempo médio.

Resumindo, se tratando de NFS-e temos que realizar testes alterando os valores das 3 propriedades acima (em negrito) a fim de encontrar a melhor performasse. Devemos lembrar que uma configuração pode ser ótima para um provedor e não ser para outro e também o que é bom para o ambiente de homologação não necessariamente será para o de produção.

Espero ter ajudado.