JJA

Hum, aqui não deu certo. Meus fontes estão atualizados com data de 2 semanas atrás, recompilei usando MINGW alterando o ACBr.inc. Qual config da SSLlib você está usando?

Certo, então por hora, só aguardar? Como o amigo acima mencionou, pode já ser feita as adaptações tentando enviar a NFe 4.0, mas o status ainda está no aguardo?

Mas você consegue dar andamento no método enviar sem que componente esteja com StatusServico OK? Não sabia dessa, por isso estacionei.

Também estou com o mesmo problema. Significa então que a Sefaz SP ainda não tem disponível o ambiente de homologação para NFe 4.0?

Mas você conseguiu resolver certo? Pois já está o passo de enviar a NFe. Ainda estou travado no StatusServiço, enquanto não conseguir a resposta, não estou prosseguindo nos outros testes

Boa tarde amigo, aproveitando o gancho, você está emitindo NFe 4.0 para qual UF? Estou com um problema nos meus testes em que não consigo executar o status serviço do componente ACBrNFe quando setado para 4.0

Consegue sim, sem problemas. Sempre usei homologação para NFe 3.10 Bom dia pessoal, ainda estou enroscado com o erro acima. O componente ACBr já foi recompilado com a define {$DEFINE USE_MINGW}. Preciso ativar o define para não usar CAPICOM {$DEFINE DFE_SEM_CAPICOM} também para trabalhar com MinGW? Não alterei mais nada no ACBr.inc a não sei o uso da MINGW.

Ah, pode deixar que compartilho sim. Fica tranquilo. Poste as mensagens de erro que está tendo para ver se descobrimos algo ok

Boa tarde sandrovillas, ainda não, consegui progredir com a atualização das DLLs e reinstalação do componente para usar TL 1.2 mas agora parei com o erro acima.

Boa tarde, fiz as alterações nacessárias, alterada as DLLs, alterado o arquivo ACBr.inc e recompilado o componente. O erro da DLL desatualizada não ocorre mais: OpenSSL 0.9.8n 24 Mar 2010, não suporta LT_TLSv1_2 Porém ocorrem outros erros: Usando a SSLLib = WinCrypt ou Capicom, ocorre a seguinte mensagem: WebService Consulta Status serviço: - Inativo ou Inoperante tente novamente. PFXDataToCertContextWinApi: Falha em "PFXImportCertStore" Erro: 80090345 Usando SSLLib = OpenSSL, ocorre o seguinte erro: WebService Consulta Status serviço: - Inativo ou Inoperante tente novamente. Erro Interno: 11001 Erro HTTP: 500 Para mim, sinceramente não importa qual SSLLib usar, desde que eu consiga usar tanto certificados A1 como A3, pois tenho clientes que usam ambas as modalidades.

Certo, eu vi esta parte, mas para facilitar a vida não seria mais facil então copiar as DLLs para ambas as pastas?

Então, mas a 'regra' não é se uma aplicação é 32bits, ele usa as DLLs da pasta system32, e se for 64bits, usa as DLLs da pasta sysWOW64? Ou não, não tem nada a ver e uma aplicação pode sim usar DLLs tanto da pasta system32 e sysWOW64 ao mesmo tempo. Desculpe se a dúvida não tem relação direta com o tópico, mas esta é uma dúvida que eu sempre tive, tanto é que no tópico sugerido, ele diz que você deve substituir as DLLs ou na pasta system32 quanto na sysWOW64 dependendo da sua aplicação.

Certo. Aqui usamos o delphi 2010, então certamente só compilar para 32bits correto? Porém percebi que algumas DLLs são usadas da pasta SysWOW64, quando estava atualizando as DLLs da pasta SysWOW64 e o ACBrNFedemo estava sendo executado junto com o meu projeto feito em Delphi 2010. Não consegui sobrepor, somente depois de ter fechado a aplicação e o Delphi. É porque ela está compilada para 64bits correto? Porém minhas aplicações feitas no Delphi 2010 são todas em 32bits.

opa, não recompilei o ACBr, sorry. Aproveitando então, me tira uma dúvida, preciso apenas recompilar o ACbr ou precisa reinstalar os componentes? Sobre o Target Platforms, não aparece este icone no meu projeto.

Antiga comparada a quais?Tenho muitas DLLs no diretório da aplicação, como eu copiei todas da pasta MinGW e substitui todas as que apareceram, imagino que as antigas foram substituídas pelas novas que eu copiei. Quais DLLs fora as da pasta MinGW poderia ser antiga e não deveria estar na pasta? Porque o que eu fiz foi apenas copiar na minha pasta da aplicação, mantendo todas as DLLS que já existiam lá.

Em relação ao tópico citado, fiz como no tutorial, copiei as DLLs da pasta MinGW para o pasta Windows\SysWOW64, também copiei para pasta do meu sistema, alterei o arquivo ACBr.inc editando a linha: {$DEFINE USE_MINGW} Agora ao executar o meu sistema, da o erro: --------------------------- Debugger Fault Notification --------------------------- Project C:\projetoXXX.exe faulted with message: 'access violation at 0x00000030: access of address 0x00000030'. Process Stopped. Use Step or Run to continue. --------------------------- OK --------------------------- e não sai dele. Se renomear novamente o ACBr.inc, o sistema executa. O que pode estar errado?

PS: Pergunta idiota, como eu sei que o meu Delphi é 32Bits ou 64bits?

Muito obrigado, vou seguir os passos do tópico.

Para SP, tanto em homologação como em produção. PS: Atualizei as DLLs libeay32.dll e ssleay32.dll para as versão 0.9.8.14 que estão disponíveis no repositório do ACBr, porém continua com o mesmo erro. WebService Consulta Status serviço:- Inativo ou Inoperante tente novamente.OpenSSL 0.9.8n 24 Mar 2010, não suporta LT_TLSv1_2 Como devo proceder para substituir essas DLLs? Sei que tem um padrão para Windows 32bits ou 64bits, para se colocar nas pastas certas, mas nunca sei e acabo sempre substituindo tanto na system32 quanto na Syswow64

Bom dia pessoal, estou testando o componente ACBrNFe com a versão 4.0 e ao executar o comando abaixo da erro usando como Capicom ou WinCrypt: ACBrNFe.WebServices.StatusServico.Executar; --------------------------- Atenção --------------------------- WebService Consulta Status serviço: - Inativo ou Inoperante tente novamente. Erro Interno: 0 Erro HTTP: 500 --------------------------- OK --------------------------- Se mudo para OpenSSL, me retorna o erro: --------------------------- Atenção --------------------------- WebService Consulta Status serviço: - Inativo ou Inoperante tente novamente. OpenSSL 0.9.8n 24 Mar 2010, não suporta LT_TLSv1_2 --------------------------- OK --------------------------- Dúvidas: - Devo atualizar a DLL para usar com OpenSSL correto? - Para Nfe4.0 não funcionará mais Capicom? Mas o WinCrypt substituiria certo?

Adicionado também ao código de retorno de consulta: Unit: ACBrNFSeWebServices.pas Função: ExtrairNotasRetorno linha: 1087 FNotasFiscais.Items[ii].NFSe.NumeroLote := FRetornoNFSe.ListaNFSe.CompNFSe.Items.NFSe.NumeroLote;

Italo, bom dia, Estou testando o código acima eme deparei com um problema: Na propriedade "ListaChaveNFeRPS", acredito que quando o RPS enviado tem algum problema, este lista está vazia, retornado "List out of bounds(0)" Eu alterei a unit "ACBrNFSeWebServices.pas" com uma validação para verificar o count da lista: - Adicionado linha logo após a linha 2262: if RetEnvLote.InfRec.ListaChaveNFeRPS.Count > 0 then Referente a esta lista, ela só é populada quando o RPS foi acesso e já virou NFSe? Posso validar se o RPS virou NFSe por esta lista? Ou tem alguma outra propriedade que me fala se o envio foi com sucesso ou não? Tem também a lista MsgRetorno, no qual me traz os erros apontados no RPS, posso garantir que se esta lista estiver vazia, o RPS virou NFse? Abraço

Juliomar, acredito ter resolvido o problema mas não achei exatamente a causa: Quando me referi que em Design Time o componente conectava e em Run Time dava o erro, só dava certo quando eu abria antes um dos meus projetos. Então identifiquei que um dos meus projetos o Zeos conectava normalmente, tanto em Desing quanto em Run Time. Achei este link na internet que mencionava outras dependências de DLL para o Zeos funcionar: https://pgolub.wordpress.com/2009/03/16/client-libraries-mess/ Então constatei que haviam DLLs dentro do projeto que funcionava que não estavam no projeto que dava erro. Tentei analisar todas as DLLs mencionadas no link e fui copiando 1 a 1 para o projeto com erro, mesmo assim sem sucesso. Então copiei todas as DDLs da pasta do projeto bem para a pasta do projeto com erro e funcionou, ou seja, era a falta ou desatualização de alguma DLL. Sobre em Design Time o projeto pelo menos conectar, era porque antes eu havia aberto o projeto que funcionava, e acredito que a DLL fica presa na memória, assim fazendo o projeto com erro conectar, mas em Run Time o EXE deve procurar as DLLs na pasta, daí o erro. Enfim, era realmente a falta ou desatualização de alguma das DLLs, mas não as DLLs libpq81.dll, libpq.dll que eu havia mencionado, e sim alguma outra, mas não sei identificar qual o nome dela pois acabei copiando varias DLLs ao mesmo tempo para ver se resolvia o problema.

Boa tarde Juliomar, acredito que possa ser isso, no pc que funciona a DLL, está instalado o Postgres 9.4 e nessa máquina que não funciona está o Postgres 9.6. Fui na pasta de instalação do Postgres 9.6 e copiei estas 2 DLLs para a pasta do EXE, mas ainda ocorre o mesmo erro. Como eu poderia ver qual a versão correta da DLL?

Boa tarde amigos, tudo bem? Espero que possam me ajudar pois este erro está me tirando o sono e não consigo achar lógica para o mesmo. Eu já desenvolvo com Delphi 2010 + Zeos em outra máquina sem problemas. Recentemente instalei o Delphi 2010 + Zeos em outro pc e estou executando o mesmo projeto que já funciona em outra máquina. Ao tentar conectar, aparece a seguinte mensagem: "None of the dynamic libraries can be found: libpq81.dll, libpq.dll" Eu tenho essas DLLs na pasta do EXE, coloquei na system32, sysWOW64 e nada, a mesma mensagem ocorre. O mais esquisito é que em Design Time também ocorria o erro ao ativar o ZConnection, mas não sei o que eu fiz que começou a dar certo, ou seja, em Design Time esta mesma mensagem que aparecia, parou de aparecer, mas ao tentar executar o connected em RunTime, ocorre o erro acima. Não sei mais o que fazer, tenho as DLLs, mas mesmo assim o sistema sente falta delas. O que pode ser?