Jump to content

dia-do-acbr-online.png

Ganhe acesso a todas Palestras
Assinando o Suporte ACBr Comercial

Saiba Mais


dia-do-acbr-online.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


botao.png

beneficios.png

messiashenrique

Membros
  • Content Count

    42
  • Joined

  • Last visited

  • Days Won

    3

messiashenrique last won the day on October 29 2013

messiashenrique had the most liked content!

Community Reputation

31 Excellent

1 Follower

About messiashenrique

  • Rank
    Membro
  • Birthday 09/13/1980

Profile Information

  • Sexo
    Masculino
  • Location
    Goiás
  • Interesses
    TI. Programação, Automação Comercial

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Olá! Antes de mais nada, o objetivo desse tópico não é cobrar nenhuma solução célere para o caso. Antes porém, abrir espaço para que possamos, juntos, encontrar um modo de resolver o problema. Primeiramente é importante salientar que o ambiente para simular o problema deve ser estritamente o seguinte: 1) Lib: OpenSSL 2) webservice de Goiás 3) Ambiente de homologação. Bom, venho há algum tempo tentando encontrar alguma solução para contornar o erro obtido ao tentar a requisição de um simples status de serviço, por exemplo, usando a configuração mencionada acima.
  2. Exatamente! Independente do Layout 3.1 ou 4.0 o ambiente de homologação do webservice de Goiás sempre retorna erro 500 quando se usa OpenSSL. No meu caso, que estou usando Linux, não tenho outra alternativa além dessa... Também tentei contato com o pessoal do atendimento, mas eles dizem que está tudo certo!
  3. Pessoal, boa noite! Ainda temos um problema com o ambiente de homologação de Goiás quando é usado a openssl. O interessante é que funciona em ambiente de produção, mas em homologação não. Vou enfatizar novamente que isso acontece apenas com a lib OpenSSL. Em Windows eu consigo contornar isso facilmente usando winCrypt, mas em Linux ainda não visualizei nenhuma solução. Entrei em contato com o suporte aqui de Goiás e eles ficaram de me responder... Mas não entendem nada quando eu digo OpenSSL e etc... Se alguém tiver qualquer ideia do que fazer, será de grande vali
  4. Muito estranho porque o a requisição específica a versão 4.0 e o servidor responde 3.1... Isso não é normal, né? Obs.: Desculpem-me, respondi ao mesmo tempo que o Ítalo... (ele postou a mesma observação)
  5. Olá Daniel, boa tarde! Já conseguiu fazer funcionar o OpenSSL e TLS1.2 nos webservices de Goiás?
  6. Excelente! É exatamente como o colega @almp1(André) citou no post. Mas se precisarem de mais informações, tem aqui , aqui para extrair as chaves do certificado... e também aqui (onde me ajudou bastante). Bem, por ora, muito obrigado @Daniel Simoes e todos que tem se esforçado nesse empreito. Att. Messias Henrique
  7. Excelente ideia. Assim, fica bem mais simples. Normalmente, era necessário fazer intervenções no código ACBr. Então, toda vez que atualizava via svn, quebrava o código... Se tiver como dar um ok aqui nesse tópico assim que esse evento estiver comitado , seria de grande auxílio. 1) Sim, no Linux 32bits é possível sem, praticamente nenhuma modificação nos fontes. Basta que as libs (open, xml2, xmlsec) sejam instaladas do jeito que o ACBr espera. Normalmente tem instalar a xmlsec no braço (make, make install) e também criar links simbólicos adequados dependendo da dist
  8. Bem Adriano. No Linux, enquanto não temos a solução para a versão 64bits, eu resolvi ficar com a versão 32bits mesmo. Já no MacOS, eu tive que improvisar e consegui chamar, por linha de comando, o executável do xmlsec que assina o arquivo. Isso também pode ser feito em Linux. Basta chamar através de um TProcess, por exemplo. Veja bem, eu disse o executável e não a biblioteca dinâmica (dll ou so ou dynlib etc...) Claro que é uma gambiarra, mas... é uma ideia... apenas. Att. Messias Henrique
  9. Olá Adriano, boa tarde! Então, na verdade, hoje é possível instalar o ACBrNFe e etc... no Linux 64bits sem, praticamente, nenhuma modificação do código baixado via svn. No entanto, como pode ser visto no tópico, que você mesmo citou, ainda estamos buscando uma solução para o pleno funcionamento. Eu também tenho acompanhado isso tudo há anos... e, agora acho que estamos bem perto de chegar nela! O erro ocorre exatamente na hora de assinar o documento. No finalzinho do tópico (linkado acima), percebe-se que que os esforços tem dado resultado. Mas, ainda não conseguimos fazer o Laz
  10. Olá @almp1, tudo bem sim e você? Então, desculpe-me pela demora... Estes dias estive ausente desse universo... (rsrsr). Só agora vi suas mensagens. Vou voltar a mexer nesse projeto a partir da semana que vem. Quem sabe a gente consegue descobrir o que se passa... Em um passado não muito distante, eu tive que improvisar nesse projeto e fiz uma gambiarra (argh!) onde eu gerava o xml pelo ACBr e depois validava e assinava pela através dos executáveis xmlsec1 e openssl (usando o TProcess) . Mas isso é horrível e acredito que é possível fazer tudo pela lib mesmo. No entanto, não
  11. Olá Daniel, bom dia e obrigado. Então, Daniel, antes cheguei a pensar isso também... Mas fiz um pequeno teste e vi que o problema não é ao carregar a Lib e sim ao criar a parte gráfica com lib carregada. Da forma que está, a lib é carregada em um handle no início da execução do método e logo depois é liberada. Fiz esse teste em um form mesmo e vi que dava certo. Então acreditei que ia funcionar também com o componente. Veja as imagens em anexo Att. Messias Henrique Agora precisamos testar em outros ambientes (principalmente Windows com Delphi - que não tenho aqui). Acredit
  12. Na linha 399 da unidade Unit1.pas do exemplo ACBrNFe_Demo temos o seguinte: edtPathSchemas.Text := Ini.ReadString( 'Geral','PathSchemas' ,PathWithDelim(ExtractFilePath(Application.ExeName))+'Schemas\'+GetEnumName(TypeInfo(TpcnVersaoDF), integer(cbVersaoDF.ItemIndex) )) ; Sugiro que alterem para edtPathSchemas.Text := Ini.ReadString( 'Geral','PathSchemas' ,PathWithDelim(ExtractFilePath(Application.ExeName))+'Schemas'+PathDelim+GetEnumName(TypeInfo(TpcnVersaoDF), integer(cbVersaoDF.ItemIndex) )) ; Isto é, troquem a "\" (barra invertida - delimitador de paths do windows) por "Pa
  13. Olá comunidade! É com imenso prazer que venho comunicar-lhes a compatibilidade dos componentes ACBrNFe, ACBrCTe e etc... em ambientes Linux 64btis. Sim. Agora é possível! Depois de um longo tempo de tentativas, resolvi, neste fim de semana, remover dotas as chamadas estáticas que haviam nas unidades: libxmlsec.pas, libxml2.pas, libxslt.pas e libexslt.pas e reconstruir apenas as necessárias com implementações que realizam chamadas dinâmicas às bibliotecas. Nenhuma modificação foi realizadas em unidades "específicas do projeto ACBr" e sim apenas nos quatro arquivos citados acima. A princípi
  14. Olá vca_rj! Eu estou migrando os meus relatórios para o LazReport que é nativo, (vem junto com os pacotes de instalação, mas precisa ser instalado). Usava o Fortes, no entanto, acredito que o LazReport já amadureceu bastante. Ele é baseado no FreeReport que é um componente free criado e mantido pela mesma empresa que desenvolve o famoso FastReport. Porém alguns componentes do ACBr (ACBrDANFe, por exemplo,) por enquanto, possuem apenas versão baseada no FortesReport. É possível implementar um DANFe em cima do LazReport, mas isso demanda um certo trabalho... Assim que eu tiver t
  15. Olá, Krahe! Que bom que você consegui instalar o ACBrCTe! Eu não precisei dele até o momento então nunca havia tentado instalá-lo. Sobre o ACBrNFe eu passei pelas mesmas dificuldades que você... Sofri demais mesmo... exatamente por conta da arquitetura das bibliotecas. Também uso o Mavericks e naturalmente ele já tem algumas libs em 64bits e quando se compila sem algumas instrução extra elas são geradas em 64bits e, enquanto isso, o Lazarus fica buscando as libs em 32bits. No entanto eu descobri que é possível, no Mac OS X ,fazer uma mesclagem de um biblioteca 32bits com a mes
×
×
  • Create New...