Ir para conteúdo
  • Cadastre-se

JJA

Membros
  • Total de ítens

    131
  • Registro em

  • Última visita

Posts postados por JJA

  1. Em 10/07/2017 at 09:30, arce disse:

    Uma dúvida. Consigo emitir uma NFe com o layout 3.10 em homologação? Ou apenas 4.0?

    Consegue sim, sem problemas.

    Sempre usei homologação para NFe 3.10

    Em 06/07/2017 at 14:43, JJA disse:

    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.

    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.

  2. 4 minutos atrás, sandrovillas disse:

     

    JJA boa tarde, conseguiu resolver a questão do status? 

    segui os passos que foi te passado, fiz igual mas não consegui nem com o certificado A1 nem com o A3.

    Aguardo, abç.

    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.

  3. 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.

  4. 2 minutos atrás, BigWings disse:

    Só quer dizer que elas estavam em uso, então você não conseguiu sobrescrever. Nenhuma relação com ser 64bits. 

    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.

  5. 16 horas atrás, BigWings disse:

    O Delphi compila pra 64bits a partir da versão XE2.

    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.

  6. Agora, BigWings disse:

    Alguma DLL antiga no diretório da aplicação?

    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á.

  7. 5 horas atrás, BigWings disse:

    Não é só copiar as DLLs.

    Leia com atenção o tópico:

     

    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?

  8. 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

  9. 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?

  10. 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;

  11. 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

     

     

  12. 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.

    • Curtir 1
  13. 25 minutos atrás, Juliomar Marchetti disse:

    Está conectando com PostGreSQL!

    veja se está com a versão da dll compatível com seu servidor.

    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?

  14. 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?

     

  15. 1 hora atrás, Célio Rafael Martins Júnior disse:

    Eu já uso no DIFAL, normalmente, só gostaria  de saber se essa utilização seria somente em operações interestaduais. Em relação as Tags da NT_2016_002_v1.00.

    Abraço.

    Também vi algo  do tipo. Pelo que vi FCP ST será dentro do estado.

  16. 2 minutos atrás, Daniel Simoes disse:

    Isso não é coberto pelo SAC... não tem com nossos consultores saberem das peculiaridade das N cidades existente...

    http://www.projetoacbr.com.br/forum/sacv2/questoes_importantes/

    Entendo, mas a minha dúvida está ligada ao componente em si não está?

    preciso saber somente como resgato o número da nota fiscal, protocolo de envio e log de erros caso o RPS seja rejeitado logo após a execução do procedimento "Enviar"



     

  17. 3 minutos atrás, Daniel Simoes disse:

    Tópico movido para fórum ACBrNFSe, para atrair a ajuda de outros usuários...

    Sem problemas Daniel,

    mas eu quero poder contar com a ajuda e agilidade do SAC ACBr uma vez que a empresa no qual trabalho optou em pagar justamente para poder ter uma maior rapidez nas dúvidas ok.  

×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.