joaoelson

Boa tarde amigos. Estava monitorando esses dois dias as transmissões das notas, aparentemente o problema é na SEFAZ VIRTUAL RS. Não fiz nenhuma modificação nas configurações e ontem pela manhã parou de apresentar o problemas de Timeout. Até esse momento 17:00 não está ocorrendo nenhum erro. Muito obrigado pela ajuda de vocês.

Boa tarde amigos. Estou com obtendo esse erro 10060 HTTP: 0 constantemente com vários clientes desde o começo desse mês com a SEFAZ Virtual RS. As configurações que estou usando são: OS: Windows 10 pro atualizado. CryptLib: cryOpenSSL HttpLib: httpOpenSSL XMLSignLib: xslibXML2 SSLType: LT_TLSv1_2 Alguém mais está tendo esses problemas? Obrigado e bom dia a todos.

Olá amigos. Irei relatar um problema que está ocorrendo com as dlls do openssl na versão 1.0.2.13, isso pode ajudar alguém. Seguinte, depois de muito bater cabeça tentando utilizar o OpenSSL com os web-services que exigem TLS, assim como os das distribuições DFe, manifesto e outros, descobri um problema que está ocasionando erros. O problema está na DLL msvcr120.dll que pertence a algumas distribuições do Microsoft C++. Alguns aplicativos como Adobe Acrobat DC ou até mesmo o Visual Studio, utilizam esta mesma DLL, porém, na versão superior a distribuída com o OpenSSL, assim como mostra a imagem em anexo. Apos algumas horas de trabalho ficou o dilema, não é possível substituir as DLLs no diretório windows, já que vai parar outros aplicativos, também não funcionará utilizando-as na pasta de seu executável, já que a prioridade são as dos diretórios System32 e SysWOW64 . Fiz todos os testes possíveis e a única alternativa foi utilizar o WinCrypt, portanto amigos, tomem cuidado antes de substituir a DLL msvcr120.dll no diretório do windows do PC de seu cliente, pode parar de funcionar outros aplicativos e isso lhe dará muita dor de cabeça. Abraço a todos.

Fiz aqui uma pequena confusão entre os campos, já que começam com o mesmo nome "cSit". O campo cSitDFe representa o campo cSitNFe do manual e não o campo cSitConf. Aparentemente não existe, até o momento, o campo cSitConf no componente ACBr. Pesquisando aqui, se trata de um problema no próprio webservices da Receita. Alguns programadores acharam uma medida "paleativa" para o problema, mas até o momento não foi incorporado ao projeto. Segue o link da discussão sobre o assunto:

Bom dia, tarde, noite senhores. Por gentiliza, alguém pode me tirar uma dúvida em relação ao retorno de consulta DFe, já procurei aqui no fórum mas não encontrei resposta. A dúvida é no campo cSitDFe do caminho: ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Items.resDFe.cSitDFe. No manual que tenho, o campo cSitConf Retorna os seguintes dados no xml: Situação da Manifestação do Destinatário: 0=Sem Manifestação do Destinatário; 1=Confirmada Operação; 2=Desconhecida; 3=Operação não Realizada; 4=Ciência. Porém, no tipo definido do campo cSitDFe tem as seguintes opções: TSituacaoDFe = (snAutorizado, snDenegado, snCancelado, snEncerrado); Estou fazendo fazendo essa consulta de forma errada? Se houve alteração no manual, alguém pode me passar o correto, já procurei e não encontrei. Desde já agradeço a ajuda.

Agora deu certo, muito obrigado. Estava apanhando a um bom tempo rsrsrsrs....

Boa tarde. Gostaria de tirar uma dúvida com os amigos do forum, referente a consulta DFe. Estou estudando os códigos com o exemplo acbr. Quando eu faço uma consulta DFe pela primeira vez, com código abaixo, retorna a consulta e tudo ok: ACBrNFe1.DistribuicaoDFePorUltNSU(StrToInt(cUFAutor),CNPJ,ultNSU); Agora se eu fizer a consulta novamente, mesmo informando um outro NSU, apresenta um erro em determinado ponto do componente, no evento TACBrNFe.Distribuicao, exatamente na linha WebServices.DistribuicaoDFe.cUFAutor := AcUFAutor, como mostra a imagem postada. A duvida é: Antes de fazer uma nova consulta eu devo fazer algum tipo de clear no componente ou coisa parecida? Oque estou fazendo errado? Agradeço a ajuda.

Segundo ouvi dizer do pessoal da certificadora isso será apenas mais uma opção à assinatura digital, mas ainda está fase de testes e está dando muitos problemas, tanto que só a Certisign está vendendo e sem ao menos explicar direito como funciona. Acredito que para NFC-e perderá a funcionalidade da emissão em off-line. Acho precoce se preocupar com isso agora, mesmo porque só empresas grandes com muitos pontos de acesso que optarão por isso, ou não.

Essa mesma que todos estão usando. Pelo visto não é só com o delphi que está dando erro, teve relatos que estava dando com o visual studio também, todos em debug. Segundo informações do pessoal do suporte da ESET só na próxima versão que sairá a correção pra esse e outros erros. Eles me mandaram uma correção via e-mail, mas não resolveu nada e estava dando vários erros. Acompanha lá no forum para ficar atualizado sobre esse problema. https://forum.eset.com/topic/16237-probleme-debug-delphi-with-eset-11249/

Se ajudar... https://www.projetoacbr.com.br/forum/topic/45021-salvar-xml-antes-de-enviar/?do=findComment&comment=297340 Tive o mesmo problema.

Antes de enviar o XML, pego a chave assim. chave := Copy(ACBrNFe1.NotasFiscais.Items[0].NFe.infNFe.ID, 4, 44); Funciona tanto em contingencia quando normal.

Mais pessoas com problemas. https://forum.eset.com/topic/16237-probleme-debug-delphi-with-eset-11249/ Parece que o problema está ocorrendo com as versões ESET Internet Security e ESET Smart Security. A solução no momento é desativar o ESET enquanto usa o delphi.

cara... não intedi nada. "não sendo aquele que pega a data - pelo nascimento". Explica melhor.

Para quem usa o antivírus ESET, hoje 30/07/2018 saiu uma atualização 11.2.49.0 que está conflitando com o compilador Delphi. Após várias horas de "quebra cabeça" descobri a "mer**" que a ESET fez. Procurei em seu fórum e constatei que o problema não é só comigo. Achei muito estranho porque até sexta-feira estava trabalhando normalmente e hoje pela manhã já não conseguia debugar nada. Você pode até compilar, mas em debbuging o delphi trava de um jeito que você não consegue fazer nada. E para fechar o delphi, somente usando o gerenciador de tarefas. Quase um dia de trabalho perdido por conta de um antivírus. ? Segue o link do forum da esset https://forum.eset.com/topic/16239-problem-with-with-eset-11249-and-debug-application/

Resolvido.. A quem possa interessar... Gravo o xml antes de enviar para evitar problema com o digestvalue. Se já existir xml não será gerado novamente, caso houver erro e o retorno for duplicidade será feito apenas uma consulta. Também para evitar o consumo indevido do Webservice, segundo NT 2018/002, controlo a quantidade de envios da mesma nota. obrigado aos amigos.