Dércio Luis Zanatta

Boa tarde Atualmente somos homologados junto a softwarexpress para utilizar o Sitef como solução para TEF dedicado. Até onde eu sei, é a única forma de fazer Transações com Cartão utilizando a solução de TEF dedicado. Existe alguma outra forma ? Existe alguma outra alternativa que não seja pela Softwareexpress (Sitef) ?

O ideal seria poder setar essas propriedades via programa.. Ai sim eliminaria de vez o problema ! Será que isso é possível criar no componente ?

Boa tarde Fiz uma alteração aqui que resolveu o problema: Eu estava utilizando o Componente ACBR dentro de um DataModule carregado na memória. O que fiz foi colocar o Componente em outro Formulário que não fica carregado em memória. Antes de usar o componente faço o carregamento do formulário (Application.CreateForm(TFrmNFce,FrmNFCe) , no final de tudo, depois de enviar, imprimir danfe, enviar e-mail etc... eu dou um Free no formulário (FrmNFCe.Free). Dessa forma não entra mais nenhuma NFCe em Contingência OFF Line, todas são autorizadas normalmente Utilizando OpensSSL + modo Síncrono.

A base de cálculo do ICMS quando o CST é 00 (tributado integralmente) sempre deve ser o valor líquido do ítem. Portanto, se foi concedido desconto, o valor líquido, nesse caso, seria 70,00

Boa tarde Fiz uma alteração aqui que resolveu o problema: Eu estava utilizando o Componente ACBR dentro de um DataModule carregado na memória. O que fiz foi colocar o Componente em outro Formulário que não fica carregado em memória. Antes de usar o componente faço o carregamento do formulário (Application.CreateForm(TFrmNFce,FrmNFCe) , no final de tudo, depois de enviar, imprimir danfe, enviar e-mail etc... eu dou um Free no fromulário (FrmNFCe.Free). Dessa forma não entra mais nenhuma NFCe em Contingência OFF Line, todas são autorizadas normalmente Utilizando OpensSSL + modo Síncrono. Espero que funcione para você também ! Abraço.

Bom dia pessoal.. Mudando as configurações no Internet Explorer realmente resolve o problema, porém em alguns casos em alguns clientes percebi que essas configurações voltam a ficar "erradas" sem ninguém mexer em nada. O ideal seria se pudessemos configurar isso diretamente no programa sem depender do Internet Explorer !

Não uso esse evento. O que eu tentei fazer foi chamar novamente a função enviar quando ocorre o erro de conexão, porém sem secesso, pois retorna erro também na segunda tentativa !

Só para confirmar... Verifiquei que a data das DLLs que estão na pasta do ACBR são de 01/10/2015 ! Isso está correto ? Não houve mais atualização de DLLs após essa data ? na pasta DLL\OpensSSL tem duas verões : 0.9.8.1 e 0.9.8.14 Atualmente estou usando d 0.9.8.14 Isso está correto ?

Já tinha feito isso.. As DLLs estão atualizadas. Andei conversando com outros usuário aqui do fórum e alguns deles me disseram que passaram por isso tb e simplesmente desistiram de usar OpenSLL e passar a usar Capicpon. No meu caso fica mais dificel, pois são muitas máquinas para gerenciar o certificado.

Boa tarde Daniel. Depois de várias tentativas para tentar descobrir o porque de tantos probelmas de conexão no envio de NFCe, cheguei a uma conclusão. O problema ocorre somente se o componente estiver configurado como Openssl. Fiz um teste agora de manhã. Em um cliente onde o problema está ocorrendo seguidamente, instalei o certificado A1 (.pfx) no windows e configurei o componente como Capicom, carregando o núemro de série do certificado. A partir dai não ocorre mais nenhum problema de conexão. Todas as NFCes enviadas depois disso autorizam sem problemas. Sendo assim, acredito que o problema não tenha relação com rede, internet ou Ws da Sefaz, mas sim com a opção OpenSSL.

Boa tarde Está confirmado.. O problema de falha de comunicação ocorre somente utilizando OPENSSL. Fiz o teste. Em um cliente meu onde ocorria bastante problema de entrar em contingência por falha de comunicação. Instalei o certificado A1 no windows e passei a usar como Capicom, passando o número de série do certificado.. Fiz isso hj as 7 horas da manhã.. Até agora nenhuma nota deu problema de conexão. Sendo assim, o problema não parece ter relação com a Rede, internet ou WS da Sefaz, mas sim quando se configura o componente como OpenSSL. Espero que esse problema tenha solução, pois vai ficar inviável ter que instalar o certificado em cada terminal de venda !! Alguém tem alguma idéia do que pode ser feito para não dar o problema como OpenSSL ?

Ola amigo... Muito obrigado por responder.. De alguma forma fico mais tranquilo em saber que não sou somente que estou com tal problema. No meu caso fica complicado de usar como Capicom, pois dessa forma teria que instalar o certificado em cada caixa do mercado refazer essa instalação uma vez por ano.. São 12 caixa em média para cada mercado (uns 30 mercados) De qualquer forma, vou fazer o teste em um outro cliente que tem um caixa somente e que ocorre o problema também, só para tirar a dúvida... Posto o resultado aqui depois..

Ontem em um cliente meu: 1361 NFCes emitidas, 96 deram o problema de conexão ! Detalhe: Internet de 40Mb via cabo, super estável, sem perda de pacotes no ping ..

Bom dia Tem mais alguém ai que use emissão de NFCe no modo OpenSSL, Síncrono ? Não estão enfrentando problemas de conexão com a SEFAZ (Erro Interno 10060 HTTP:0) com muita frequencia ?

Bom dia O CSC e ID do CSC não são jogados no xml,(não de forma individual ou implícita). São usados para compor o QrCode da NFCe. Vc deve informa-los apenas nas configurações do componente mesmo. abraço.

Certo... Estudando esse probelma, notei que quando ocorre o probelma de conexão HTTP:xxxx , na próxima tentativa de envio vai normal, sem ocorrer o erro. Pensei em fazer mais de uma tentativa para o envio.., ou seja, ao invés de um TimeOut de 10 seg, fazer duas tentativas de 5 seg.. Estive analisando a seguinte rotina: function TWebServices.Envia(ALote: String; const ASincrono: Boolean): Boolean; begin FEnviar.Lote := ALote; FEnviar.Sincrono := ASincrono; // Nesse ponto pensei em alterar para executar novamente Enviar.Executar tantas vezes quanto estiver configurado a propriedade Tentativas do componente. if not Enviar.Executar then Enviar.GerarException( Enviar.Msg ); if not ASincrono then begin FRetorno.Recibo := FEnviar.Recibo; if not FRetorno.Executar then FRetorno.GerarException( FRetorno.Msg ); end; Result := True; end; Não me sinto muito a vontade em mexer nos fontes do componente ehehehehe Qual sua opinião sobre isso ?

No ACBR existe a propriedade TimeOut e existe a propriedade Tentativas. Estive olhando nos fontes e vi que o TimeOut é usado no processo de envio, porém não encontrei a propriedade "Tantativas" sendo usada no processo de envio. Onde exatamente ela é usada ?

O fato é que o problema ocorre em todos os clientes, incluisve aqui na empresa me homologação !

Bom dia Vou providenciar esse teste Daniel. Lhe ocorre alguma outra idéia da causa dessas falhas de comunicação em uma internet tão estável ?

Estou cada vez mais convencido que o FastMM4 tem alguma relação com esses problemas de conexão. Compilei meu aplicativo com o FastMM4.pas no dia 31/10/2016 e o cliente foi atualizado com essa versão no dia 01/11/2016. Estive fazendo alguns levantamentos agora a pouco.... Antes do dia 01/11/2016 o número de erros de conexão (HTTP:0) era de 8, em média... a partir do dia 01/11/2016, fica sempre acima de 30 !! Não parece apenas coincidência. O Problema é que não posso tirar o FastMM4 de minha aplicação, pois ele resolveu em 100 % os problemas de "out of memory" que vinham ocorrendo em meu sistema. "sinuca de bico" ehehehhee

Bom dia pessoal.. Parece que esse problema do Time-out está contornado... Estou acompanhando e agora está obedencendo o Time-out definido no Componente O que ainda me parece muito estranho é a quantidade de erros de conexão que acontecem. Nessa filial, desse cliente que estou acompahando, tem uma internet de 40mb, tudo via cabo, sem rádio.. sem proxy, tudo liberado... Mesmo assim, cerca de 5 % do total das NFCes emitidas no dia apresentam Essa falha de conexão (HTTP:0 u HTTP:500) Não parece lógico ser um problema de Internet.. porém não sei o que poderia estar causando isso !

1 - Alterei o arquivo FastMM4Options.INC as seguintes linhas: {.$define FullDebugMode} para {$define FullDebugMode} e {.$define ClearLogFileOnStartup} para {$define ClearLogFileOnStartup}

Sim claro.. Entendo... Só me ocorreu de perguntar se existe alguma forma de habiliar/Desabilitar o uso durante o programa. Se isso não existe, infelizmente os clientes vão ter que conviver com algumas NFCes entrando em contingência, pois os problemas que ocorrem sem usar o Fastm são muito maiores.. Se tivesse uma forma de Desativar o Fastm antes de realizar o envio e ativar novamente depois, ficaria perfeito.. No Delphi 2010 existe esse problema de alocação de memória também ? Se eu migrar para 2010, precisaria linkar o FastMM4.pas também ?

Pior que é Elton. Nos clientes que tenho uma versão anterior a de ter implementado o FastMM4 não entra nenhuma NFCe em Contingênica. É só colocar essa versão compilada com FASTMM4 que ocorrem várias durante o dia.

Ocorre em todos. Fiquei desconfiado depois que debugei o programa em busca de onde ocorria problema e notei que o processamento foi desficado para o FastMM4.pas alguma vezes. Tem lógica ser isso, pois depois que inclui o FastMM4 em meu sistema as ocororrências de NFCe entrando em contingência por falta de comunicação se tornaram constantes, enquanto antes eram muuuuuitooo raras. Por isso queria ver se existe alguma maneira de "desativar" o FastMM4 e ativar novamente, só para tirar a dúvida mesmo.