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.

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.

Tenho exatamente o mesmo problema, mas com o provedor thema, se utilizo o trunk a nota processa rapidinho, mas com os fontes do trunk2 leva de 4-6 minutos por nota.

Bom dia Daniel, Para complementar, consegui gerar o mesmo erro que está ocorrendo para vocês e mais alguns usuarios do ACBr, ele não ocorria para mim pois utilizo o Delphi em uma VM com windows XP e ele só está ocorrendo em Windows 7 ou superior. Eu comentei a parte que deu erro aqui e funcionou, consegui emitir a nota tranquilamente, mas agora estou enfrentando outro problema, uma LENTIDÃO muito grande. Não sei o que é mas se eu uso o ACBr do Trunk funciona normal e rapido, mas com o Trunk2 o servidor da prefeitura demora demais para me retornar a resposta dizendo que a nota foi processada, demais mesmo (5 min +/-). Bom, o que quero dizer é que aquele trecho no caso do provedor thema realmente não é necessário então pode comentar ou fazer algum tratamento sem estresse, mas se tiver lento ai também agradeceria se tiver algum resultado.

Boa tarde, Pelo que me diz eu deduzo que está ocorrendo algum erro mas não estoura exception. Faça o seguinte: Debugando, entre no metodo enviar da nfse, vá entrando até chegar na parte onde tem a assinatura do XML de envio, passe e entre no metodo Envia, em seguida entre no metodo Executar. Lá dentro do executar ele monta todo XML de envio, nele entre no metodo EnviarDados. Dentro desse metodo é enviado via SOAP o envelope com o xml de envio, dentro daquele while quando fizer o envio vai ter um retorno de nome FPRetornoWS, veja qual retorno você obtêm e mande aqui. Eu tive problema com isso, que esse retorno ele passa por um tratamento e quando passa pelo tratamento acontecia de retornar vazio, assim não dando erro nem um mas também não funcionava.

Bom dia Daniel, Tem algum motivo para você usar a TAG XML para gravar separadamente? Porque não deixa essa gravação por conta do ACBr? Pois para mim essa tag também está vazia depois do envio e não me afeta em nada isso. Outra coisa, a nota chega a fazer a emissão para prefeitura? Digo, ela mesmo com esse erro consta no servidor da prefeitura? A Propriedade do componente ACBrNFSe - Configuracoes - Geral - ConsultaLoteAposEnvio está marcada como True? Outra coisa interessante que acontece aqui pra mim, é que essa Consulta de Situação do Lote demora muito, estourando o limite de tentativas padrão do ACBr, dai eu aumentai esse limite pra 5000 tentativas, pra ficar tentando ate dar, sem essa consulta de situação ele não Imprime o DANFSe e porque não consegue fazer a consulta de rps enquanto a situação da NFSe não estiver processada no provedor da prefeitura. Para o ACBr efetuar a gravação dos arquivos é só marcar como true essas configurações: Configuracoes.Arquivos .Salvar:= True; Configuracoes.Geral.Salvar:= True; e eu ainda marco: Configuracoes.Arquivos .EmissaoPathNFSe:= True; Configuracoes.Arquivos .SepararPorMes:= True; E não esqueça de preencher todos os path do ACBr.

Boa tarde! Daniel, eu utilizo também SSLLib := libCapicomDelphiSoap e aqui está ok. Você instalou certinho as DLLs, conforme tem o instalar.txt? Seu certificado está funcionando certinho? Caso sim, tente fazer o que vou dizer abaixo, não é para esse seu problema, maas eu utilizei ele para um problema de segurança na hora de emitir: Vá no Painel de controle, opções de internet, vá na aba avançado, lá role até o fim e deixe marcado apenas: Usar SSL 2.0 e USAR TLS 1.0 Desmarque as opções: Usar SSL 3.0, Usar TLS 1.1 e 1.2, se estiver marcado. Mas ainda acredito que seja um problema de certificado ou instalação apropriada das DLLs.

Boa tarde Daniel, Você está fazendo um envio normal ou sincrono? Pois somente configurei o Recepcionar e não RecSincrono, pode ser isso, mas também vi que esse erro vem do SSL, e uso CAPICOM, e não cheguei a passar por esse erro dai não sei como ajudar nisso.

Segue Arquivo Thema.ini configurado, mas com url só de Lajeado. Fiz uma alteração na classe ACBrNFSeConfiguracoes para que leia as urls de homologação igual as de produção, quando na URL de Remessa tenha '*******'. Na Classe pnfsCancNFSeResposta adicionei um if para o provedor Thema, pois ele não tem na resposta do Cancelamento a tag Sucesso, e isso gerava um erro pois o valor estava vazio e consecutivamente o erro também, mesmo que estivesse cancelado com sucesso, dai tratei para que quando for o Thema e a Data do Cancelamento estiver preenchida ele preenche a tag Sucesso com Sucesso. Thema.ini ACBrNFSeConfiguracoes.pas pnfsCancNFSeResposta.pas

Bom dia, consegui fazer funcionar a NFSe para o provedor Thema de Lajeado/RS, consulta de situação + consulta e remessa. Porem agora precisaria de uma ajuda, reparei que está absurdamente lenta a consulta da situação, ele fica diversas vezes retornando que ainda está sendo processado o Lote, mas se eu emitir a mesma nota com os fontes do trunk ele emite rapidinho. Já verifiquei todas urls, estão igual ao trunk, o envelope de envio não tenho certeza se está igual, mas acredito que se tivesse problema nele daria um erro. Outra coisa, quando ele vai gravar o xml de consulta não estã removendo os caracteres #$A do retorno, tem alguma configuração, no .ini ou no componente para que salve com o retorno limpo? Assim que terminar vou disponibilizar o .ini configurado para lajeado, dai é só adicionar as urls das outras cidades. Obrigado.

Não, dentro do Thema.ini, na parte que você configura as url do WebService, lá você adiciona o citado pelo colega acima, não esqueça da linha RecepcaoLoteRPS=******* Sem ela o ACBr não vai identificar pelo código do municipio.

Como respondido acima já, tem sim como, mas é preciso alterar algumas coisas no código fonte para isso, também preciso da NFS-e para Lajeado/RS e estou tentando resolver alguns problemas relacionados a NFSe, já que não quero utilizar ambos fontes juntos, acima já disponibilizei o Thema.ini pre-configurado, estou agora tentando resolver um problema relacionado a consulta da NFSe, o envio já está funcionando.

Boa tarde, estou trabalhando no thema.ini para cidade de Lajeado - RS. O envio pelo thema está ok, meu problema agora se encontra na consulta, pois preciso do xml de retorno do envio para gerar o DANFSe. Vi que a Boolean ConsultaLoteAposEnvio na classe ACBrNFSeConfiguracoes que não era lida no txt de configuração então fiz um ajuste, não sei se é o certo, porem ainda assim estou com alguns problemas, como fica a questão de url do wsdl no txt? Por exemplo, a recepção é assim: RecepcaoLoteRPS=http://nfsehml.lajeado.rs.gov.br/thema-nfse/services/NFSEremessa?wsdl A Consulta seria assim? ConsultaLoteRPS=http://nfsehml.lajeado.rs.gov.br/thema-nfse/services/NFSEconsulta?wsdl; Segue em anexo a classe ACBrNFSeConfiguracoes e Thema.ini Para lajeado funciona, se for outra cidade tem que ver as urls. thema.ini ACBrNFSeConfiguracoes.pas