messiashenrique
-
Total de ítens
42 -
Registro em
-
Última visita
-
Days Won
3
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por messiashenrique
-
-
4 horas atrás, BigWings disse:
Testei o status agora para GO, NFe e NFCe, produção e homologação, 4.00 e retornou normalmente, exceto para SSLHtpLib = httpOpenSSL que retorna erro 500 em homologação por algum motivo.
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! -
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 valia a ajuda. Mas, por favor, tem que ser com OpenSSL.
Desde já, grato pela atenção de todos.
-
2 horas atrás, bilogyn disse:
Atualizei ontem para a Versão 13692
A minha configuração é a seguinte:
SSLLib := libWinCrypt;
SSLCryptLib := cryWinCrypt;
SSLHttpLib := httpWinHttp;
SSLXmlSignLib := xsMsXml;Pasta Schemas atualizada
Rejeição: Cabeçalho - Falha no Schema XMLMuito 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)
-
Em 04/07/2017 at 18:25, Daniel Simoes disse:
Realmente não está funcionando com OpenSSL e TLS1.2... mas aparentemente funciona com a WinCrypt... preciso investigar com mais calma...
Olá Daniel, boa tarde!
Já conseguiu fazer funcionar o OpenSSL e TLS1.2 nos webservices de Goiás?
-
5 horas atrás, Daniel Simoes disse:
O Evento foi criado... commit [r12363]
Excelente!
5 horas atrás, Daniel Simoes disse:No tópico abaixo, o colega @almp1, cita um exemplo de como usar o "xmlsec" por linha de comando para efetuar a assinatura do XML
É 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
-
1
-
-
25 minutos atrás, Daniel Simoes disse:
Estou sem tempo para (tentar) corrigir o suporte a XMLSec em 64 bits de forma definitiva...
De forma paliativa, vou criar eventos em TDFeSSL, que permitiriam um "callback" para a aplicação. Isso permitiria por exemplo que a própria aplicação, cuide do processo de assinatura, usando a linha de comando (com TPorcess)
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 hora atrás, Adriano Zanini disse:Messias, interessante a ideia.
Me veio duas duvidas com seu comentario:
1 - É possivel então, usar o ACBr 100% sem modificações, no Linux 32 bits?
(lembrando que, pra usar no Linux 64 bits tive de usar aqueles .pas modificados que peguei num post, que comentei aqui)2 - Tem como passar uma dica de como chamar esse executavel do xmlsec (e assinar)?
(TProcess do Lazarus, não tem segredo... é facil de usar)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 distribuição.
2) Até amanhã, eu ṕosto aqui uma maneira de chamar o executável (xmlsec1) para assinar o xml. (a título de sugestão, é claro)
Att.
Messias Henrique
-
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
-
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 Lazarus (ACBr) gerar a bendita assinatura. (Lembrando que possível assinar manualmente via terminal e etc...)
Neste último sábado, fiquei horas pelejando também, mas não tive nenhum avanço.
Sugiro que leia o tópico e faça testes no código das bibliotecas xmlsec e etc... Talvez você consiga ver algo que não vimos ainda.
O fato é que, somos nós mesmos quem temos que resolver.
Bem vindo ao fórum.
Att.
Messias Henrique
-
Em 29/12/2015 at 16:54, almp1 disse:
Olá Messias, tudo bem ?
Estou usando um ambiente similar ao seu
Ubuntu 15.10 64, Lazarus 1.4.4, FPC 2.6.4, e ACBr do Trunk2.
Substitui as libs do ACBrSSL pelas suas, e cheguei no mesmo resultado que o seu. Porém no momento de assinar a nota, encontro um problema na function xmlSecCryptoDLLoadLibrary, quando passamos pela linha Result := DoGetxmlSecCryptoDLLoadLibrary(crypto); recebemos uma exceção 'External: SIGSEGV';
Infelizmente não consigo passar deste ponto, também não temos como debugar isso.
Uma curiosidade é que quando usamos as bibliotecas baixando os fontes e compilando localmente, não é gerada exceção mas a função retorna (-1).
Você consegue assinar a nota? Você poderia me dar uma dica de como continuar a partir daqui ?
Abraços
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 cheguei a tentar dessa última vez... Embora, provavelmente, irei esbarrar no mesmo problema que você.
Dessa vez estou mais otimista... Assim que tiver iniciado os testes volto aqui para dar um parecer, ok?
Att.
Messias Henrique
Em 24/11/2015 at 12:32, EMBarbosa disse:Se ela é baseada no projeto libxml2-pas, o @messiashenrique poderia enviar um push-request diretamente para eles. O que acha messiashenrique?
Olá @EMBarbosa, tudo bem, né?
Desculpe-me pela demora ao responder... Estive ausente alguns dias...
Então, acho que ainda temos que ajustar algumas coisinhas.... Assim que conseguirmos corrigir alguns detalhes, vou sim tentar entrar em contato com o pessoal do libxml2-pas para sugerir as mudanças... (embora tenho a impressão - só a impressão mesmo - que o projeto está meio parado).
Enfim, não custa nada tentar!
Att.
Messias Henrique
-
1
-
-
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).
Acredito que funcione, mas é bom testar!
Att.
Messias Henrique
-
1
-
-
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 "PathDelim", por exemplo. Assim, funcionará no Windows e Linux com a mesma eficiência.
Att.
Messias Henrique
-
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ípio, percebi que era possível recriar a LCL (Lazarus) se não fosse realizado nenhum vínculo estático com libs 64bits (ou universais - caso MacOS). Logo resolvi reimplementar todos os métodos existentes nessas bibliotecas com chamadas dinâmicas. No entanto, qual foi minha surpresa, existem milhares (sem exagero) de métodos com vinculação estáticas nesses arquivos. Só no libxml2, para se ter uma ideia, depois de criar um pequeno automatizador para me auxiliar na conversão, o arquivo ficou com mais de 35 000 linhas
e alguns erros em funções desnecessárias ao funcionamento dos componentes do ACBr. Logo, eu resolvi recriar apenas aquelas que eram necessárias (algumas dezenas). Feito isso, consegui compilar, recriar a IDE e fazer funcionar o componente ACBrNFe (acredito que outros também funcionarão, já que não houve nenhuma modificação ao nível deles).
Reforçando: Todas as modificações se deram nos quatro arquivos já citados acima que fazem parte do pacote ACBrOpenSSL.
As unidades modificadas podem ser encontradas em https://github.com/messiashenrique/xmlsec4pascal e em anexo nesse post.
Gostaria de salientar que estou fazendo testes em ambiente Linux 32 e 64bits (usando Ubuntu 15.10). Portanto, ficaria muito grato se alguém pudesse testar no Windows tanto com Delphi como com o próprio Lazarus.
Obs.:
Tentei postar aqui os prints de tudo funcionando e as próprias unidades modificadas, mas aparece um janelinha dizendo que só posso fazer upload de 1024kb, sendo que as unidades zipadas medem 83kb e os prints também são pequenos.
Qualquer dúvida quanto a instalação,, ou outra qm que eu puder ajudar, coloco-me a disposição.
Att.
Messias Henrique
-
5
-
-
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 tempo, vou tentar...
Att.
Messias Henrique
-
1
-
-
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 mesma biblioteca em 64bits (usando o LIPO) aí você tem um lib mista. Isso foi ótimo... Só assim consegui instalar o ACBrNFe, porém esse não foi o fim dos problemas.
Quando fui fazer testes de utilização, esbarrei no problema da assinatura... a função que realizava a assinatura não era encontrada na lib... Fiz de tudo, mas não consegui resolver da maneira "politicamente correta"... Então apelei para uma chamada ao executável do "xmlsec1" e fiz a assinatura por debaixo dos panos...
No final eu vi que tinha feito tantas modificações no componente que estava inviável compatibilizar com outras plataformas (S.O.'s). Logo, nem tive coragem de mencionar aqui no fórum rsrsrs.
Não sei se você chegou ater esses problemas de assinatura do xml. Se tiver e encontrar uma solução melhor, adoraria saber...
Ah! Não sei como você resolveu a questão das libs (32bits)... Se fez igual eu fiz...
Talvez podeŕiamos alinhar as nossa soluções e conseguir tratar dentro de diretivas específicas para o DARWIN, assim seria possível manter o mesmo código do componente oficial...
Vou voltar a mexer na bagunça que fiz em breve... Talvez olhando novamente vejo uma solução mais razoável...
Vou torcer para que os componentes que você instalou funcionem perfeitamente. E se assim ocorrer, gostaria de saber como compilou as libs (principalmente a libxmlsec), ok?
[]'s Messias Henrique
-
Fiz a instalação do pacote xmlsec, mas não deu certo.
Quem conseguiu poderia me dar uma ajuda?
O erro que acontece é:
/usr/bin/ld: cannot find -lxmlsec
/usr/bin/ld: cannot find -lxslt
Olá, Júlio!
Antes de mais nada, devo adiantar que consegui instalar e utilizar o ACBrNFe no Linux 32bits (apenas).
Você deve instalar o xmlsec pelos fontes (compilando manualmente pelo terminal) . Não funciona com pacotes pré-compilados (tipo apt-get etc...)
Depois você precisa setar a biblioteca para o diretório /usr/lib/ através de links simbólicos...
Se tiver alguma dúvida de como fazer, posta aí que explico melhor.
Já na arquitetura 64bits eu não consegui ainda... (vou tentar novamente dentro de alguns dias).
Att.
Messias Henrique
-
Sei que esse tópico esta antigo, talvez já tenham resolvido. Mas esse fim de semana me deparei com o mesmo problema, pois fui implementar pela primeira vez no Linux o ACBR.
Depois de 3 dias de muito trabalho estou com tudo funcionando perfeitamente inclusive o ACBRNfe no Linux 64bits c/ Lazarus 1.0.12, 1.0.14 ou 1.2.0.
É muita coisa para digitar aqui, então quem tiver interesse entra em contato por email.
Olá, Ricardo!
Eu tenho muito interesse.
Mas não consegui visualizar seu e-mail....
As modificações que você fez estão a cerca do ambiente ou do próprio componente?
Pergunto pois, para conseguir fazer funcionar em Mac OSX eu sofri bastante, tive que alterar muita coisa no componente chamando diretamente o executável do OpenSSL para realizar algumas funções e isso tornou o componente praticamente incompatível para outros ambientes. Até que dava para compatibilizar, mas acho que não seria do agrado dos outros usuários... Até nem havia mencionado isso aqui no fórum.
Eu consegui emitir perfeitamente em Linux 32bits sem alterar nada no componente, como não havia tido sucesso na versão 64bits, instalei a 32bits e não tentei mais... Seria uma boa voltar a usar a 64bits.
Se você puder compartilhar, será de muita valia.
Att.
Messias Henrique
-
1
-
-
Olá amigos, estou efetuando o download do xml certinho, porém meu cliente solicitou a alteração no sistema que ao efetuar o download o nome do arquivo xml fosse composto pela chave da nfe + nome do fornecedor + número da nfe + data emissão. Já procurei e tentei renomear o arquivo via componente mas não consegui, alguém saberia me dizer se isso é possível e como devo fazer?
Olá, Rodrigo!
E possível sim.
Você pode fazer da seguinte forma:
Pegar o arquivo original (provavelmente apenas com o número da chave) e carregar ele no componente ACBrNFe. Em seguida use as funções de leitura do XML para preencher as variáveis locais. Depois basta renomear o arquivo usando as variáveis e deletar (caso queira) o arquivo original.
Ficaria mais ou menos assim:
procedure TForm1.Button1Click(Sender: TObject); var chave, fornecedor, numNF, dataEmissao: String; begin ACBrNFe1.NotasFiscais.LoadFromFile('9999999999999999999999999999999999999999NFe.xml'); with ACBrNFe1.NotasFiscais.Items[0] do begin chave := NFe.procNFe.chNFe; fornecedor := NFe.Emit.xNome; numNF := IntToStr(NFe.Ide.nNF); dataEmissao := DateTimeToStr(NFe.Ide.dEmi); end; CopyFile('C:\localArqOriginal\9999999999999999999999999999999999999999NFe.xml', 'C:\localDestino\'+chave+fornecedor+numNF+dataEmissao+'.xml', True); DeleteFile('C:\localArqOriginal\9999999999999999999999999999999999999999NFe.xml'); end;Espero ter ajudado!
Att.
Messias Henrique
-
1
-
-
Então gente, infelizmente eu não possuo Delphi.
Mas acredito que a retirada da função na linha que mencionei não acarretará em nenhum problema para usuários de qualquer versão do Delphi.
Pelo que vi em "ACBrUtil.pas" a função ACBrStr transfroma de Ansi para UTF8 e não o contrário. Logo pelas próprias diretivas de compilação era será ignorada nas versãoes mais antigas do Delphi.
Há também diversas chamadas dessa função, que na minha humilde opinião são desnecessárias. Veja por exemplo na linha 150 do "ACBrConsultaCPF.pas"
if Pos( ACBrStr('Erro na Consulta'), Str) > 0 then Res:= 'Catpcha errado.';Acredito que, nesse caso, a string em questão não sofrerá nenhuma modificação
Por outro lado, dependendo da situação, talvez se faça necessário usar a função ACBrStrAnsi da unidade "ACBrUtil.pas" pois essa sim pode ser útil para versões que não suportam unicode em muitas situações.
Testei em Linux e MacOS (ambos com Lazarus) e funcionou a contento.
Att.
Messias Henrique.
-
Realmente Daniel. No entanto, a resposta já está sendo retornada em UTF8. Logo, por alguma razão, a função ACBrStr além de desnecessária provoca um erro de Encoding. Testei no Lazarus (Linux) e funcionou perfeitamente (após a modificação).
Se alguém puder verificar em Delphi < 2009. Acredito que não dê problema.
Att.
Messias Henrique
-
Olá Régys!
Eu verifiquei e realmente havia um erro de Encoding. Porém, o componente faz uma busca por nomes (praticamente todos com acentos ou cedilhas...) que não eram encontrados dentro do StringList. Este estava recebendo duas vezes uma função de Encoding... (ACBrStr) da Unidade ACBrUtil.pas.
Quanto à mensagem de erro não havia (só debugando mesmo), pois os campos apenas voltavam vazios.
Bem resumindo, bastou modificar um mísero detalhe na linha 183 do arquivo acbrconsultacpf.pas. (seguem em anexo).
Estava assim:
linha := ACBrStr(UpperCase(Texto[i]));
e eu mudei para:
linha := UpperCase(Texto[i]);
Testei no Lazarus/Linux e funcionou perfeitamente. (Acredito que funcione também no Delphi)
Abs.
Messias Henrique
-
Acho que a resposta está meio "fora de tempo", mas ... nunca se sabe.
Para baixar o xml não é complicado de implementar (ruby provê inúmeras facilidades para lhe dar com isso.)
Já para imprimir o Danfe a partir do xml, (isso sim, daria um trabalhinho se já não tivesse pronto rrsrsr).
Como você imaginava já existe uma gem pra isso. E funciona perfeitamente: https://github.com/taxweb/ruby_danfe
O nome dela é "Ruby_Danfe". É super simples de usar, mas se ainda sim tiver dúvidas, é só postar, ok?
abs.
Messias Henrique
-
1
-
-
Olá Daniel!
Não notei nenhuma diferença no arquivo "Retrato"...
E a linha modificada, acredito que não funcione... Não sei se em TRLLabel é diferente... mas em TFont o correto seria atribuir um valor Booleano... Algo como:
Label1.Font.Bold := True;
Você tem razão. a sintaxe correta deveria ser
...font.bold := true;
Mas é óbvio que isso teria o mesmo efeito que
...font.style := [fsbold];
que é o que está no arquivo original.
O fato é que estava dando erro apenas no Linux, aí investiguei melhor e vi que a unidade "Graphics" estava declarada dentro de uma diretiva {$IFDEF MSWINDOWS}, o que faz com que fique fora de escopo do compilador no Linux. No entanto, essa unidade (Graphics) pode ser declarada abertamente sem restrições, então apenas modifiquei isso.
Ah! também me equivoquei quanto aos arquivos. Um deles é realmente o "ACBrNFeDANFeRLPaisagem.pas" porém o outro é o "ACBrNFeDANFeEventoRLRetrato.pas".
Estou anexando os dois arquivos com a simples alteração da forma de declarar essa unidade. Peço a gentileza de verificar, quando puder, é claro.
Mais uma vez, obrigado pela atenção!
Att.
Messias Henrique
-
3
-
-
Olá Pessoal!
Desculpem-me pela demora ao voltar a este tópico. Infelizmente os últimos dias não foram fáceis (minha esposa perdeu o bebê que esperávamos...), mas vamos ao que interessa:
Daniel e Juliomar obrigado pela pronta disponibiliade em avaliar as modificações no "ACBrECFBematech.pas" e subirem ao repositório.
Você já algum tempo atrás fez um tópico aqui no fórum sobre seu objetivo de portar E até onde eu sei, foi muito bem recebido pelos outros desenvolvedores, inclusive com o Daniel lhe ajudando. Eu mesmo postei lá me oferecendo a ajudar, embora não faça nenhum uso dos sistemas operacionais mencionados.Então, eu particularmente esperava que você voltasse no fórum postando os erros e dificuldades que tinha encontrado ou postando o código com os sucessos que tinha obtido. Mas não esperava um post dizendo que está tendo problemas a atualizar faz tempo por causa de correções que fez no código que você ainda não disponibilizou para os outros.
Elton, obrigado pelos elogios e também por expor sua opinião sobre os trechos grifados do meu post. Realmente, pareceu apelativo e concordo com você sobre a necessidade de contribuir para fortalecer a comunidade...
Contudo, não para justificar, mas sim para desfazer qualquer confusão, desde sempre o meu propósito é colaborar com o projeto. No tópico que você mesmo citou (sobre a instalaçao dos componentes no Mac OS X) nao sei se observou bem, mas eu enviei todos os arquivos que consegui modificar para a instalação dos componentes que consegui fazer funcionar no Lazarus/MacOSX. Foram pequenas alterações, mas ainda assim fiz questão de enviar. Inclusive o Daniel fez algumas modificações a partir dessas e o próprio arquivo "ACBrBematech.pas" (que eu mantinha como cópia para pos atualização via svn) já havia sido enviado na ocasião. Mas deixa isso pra lá. Estou relatando só para frisar que pretendo, à medida que conseguir, contribuir efetivamente com o ACBr.
Bem, não tive muito tempo essa semana, mas estou enviando outros dois arquivos ("ACBrNFeDANFeRLPaisagem.pas" e "ACBrNFeDANFeRLRetrato.pas") ambos do diretório de fontes do ACBrNFe2. Fiz uma modificação bem simples em cada um deles: apenas troquei a linha (linha 1004 no ACBrNFeDANFeRLPaisagem)TRLLabel((TRLBand(RLNFe.Controls[b])).Controls[i]).Font.Style := [fsBold];
por essa:
acOSXTRLLabel((TRLBand(RLNFe.Controls[b])).Controls[i]).Font.Bold;
Isso porque houve um problema com antiga linha na compilação do pacote no Lazarus em ambiente Linux (a versão do FortesReport é a mais recente).
Só para ficar claro, esse problema só ocorreu na instalação do ACBrNFeDANFeRL no Lazarus/Linux. No windows funciona das duas formas.
Acredito que também vai funcionar no Delphi.
Nesse caso específico, não testei no Lazarus/MacOSX, pois ainda não consegui instalar o ACBrNFe nesse ambiente nem no Linux 64 bits.Aliás, já perdi algumas madrugadas tentanto, mas ainda não sei porque o "xmlsec" está "empipinando"... Já compilei manualmente tudo que pude imaginar... (libxml2, libxslt e libxmlsec) além de outras dependências, mas por enquanto nada... Vou continuar tentando, uma hora sai...
Estou anexando os dois arquivos modificados, peço que vejam a viabiliadade de subí-los ao svn.
No mais, agradeço mais uma vez pela atenção de todos.
Att.
Messias Henrique
-
1
-
-
Olá Juliomar!
Então, conforme você mesmo sugeriu, segue em anexo o arquivo "ACBrECFBematech.pas" com as devidas correções e já testado, no Lazarus, nas plataformas Windows, Linux e MacOS. Nesses ambientes está tudo funcionando perfeitamente.
Peço, por favor, a quem tiver condições, a gentileza de testar no Delphi / Windows. Apesar de que não acredito que haverá algum problema, é sempre bom prevenir.
Talvez o meu post inicial tenha "soado" de forma meio estranha, mas o meu objetivo é simplesmente me oferecer para ajudar nesse sentido. Como eu já disse, acompanho a história do ACBr há muito tempo, usando e apreciando, e sei das dificuldades de manter um projeto como esse.
Daniel, quanto ao uso de um computar da Apple para PDV, eu também acho meio estranho / ilógico, mas não descarto totalmente. No entanto, considero muito mais ainda a possibilidade de uso de outros componentes do ACBr para aplicativos no sistema da maçã. Como exemplo, podemos citar ACBrNFe, ACBrNFSe e tantos outros que serão muito úteis para quem deseja usar o computador pessoal (macbook, por exemplo) também na empresa.
Nesse momento mesmo, estou tentando desenvolver para um amigo, um aplicativo que fará agendamento dos seus clientes e controle financeiro do seu consultório. Ele quer que o aplicativo rode em MacOS X. Estou usando alguns componentes do ACBr para isso. Coisas simples, mas que estão sendo úteis.
Sobre a forma de testar diariamente usando um servidor que o faça automaticamente, acho que é possível... Tenho que pesquisar um pouco mais... Atualizar através de uma tarefa agendada é fácil, o problema é compilar e descobrir se deu certo ou não... Talvez dê para pegar a saída pelo console... confesso que ainda não sei. Mas vou pensar mais. Desconheço os detalhes de como os snapshots do lazarus são feitos.No mais, sempre estou disposto a contribuir com o projeto.
Att.
Messias Henrique
-
2
-
e alguns erros em funções desnecessárias ao funcionamento dos componentes do ACBr. Logo, eu resolvi recriar apenas aquelas que eram necessárias (algumas dezenas). 
ACBrNFe com OpenSSL - Homologação - Goiás
em NFe/NFCe - Nota Fiscal Eletrônica
Postado
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.
Na imagem, vemos a mensagem de erro retornada:
Vou ressaltar novamente que o erro acontece no ambiente de homologação...
Em produção, tudo ok, como pode ser observado abaixo:
Eu já li praticamente todos os tópicos do fórum sobre esse erro e outros parecidos...
Não tenho como garantir (ainda), mas em alguns casos, citam como justificativa que isso ocorre porque o servidor (GO) redireciona para um site não seguro. Porém, eu acredito que isso não procede.
O quê eu acredito que está acontecendo:
1) A mensagem de erro é bem clara: "alert unknow CA" (Isso não nos quer dizer que o servidor espera, na requisição, a definição de um CA???)
2) A nota abaixo é antiga, mas acho que está sendo aplicada, no entanto, na nota os ambientes estão trocados... (o ambiente de homologação é que exige a cadeia completa):
No entanto, tentei fazer uma inspeção nos servidores e obtive o seguinte:
Homologação:
Produção:
Não consigo definir ao certo, pelo resumo qual é a diferença que provoca esse erro...
Contudo, sei que usando outras bibliotecas, como por exemplo, winCrypt, não se esbarra nesse erro. Ou seja, isso é resolvido aqui do lado cliente.
Logo, penso que podemos atacar o bind da openssl (pascal) que o ACBr usa. Já li e reli todo o arquivo, mas o meu conhecimento em C é muito raso e eu ainda não consegui descobrir qual chamada deveria ser alterada...
Ainda tenho a preocupação da incerteza de isso ser possível usando a OpenSSL 1.0.x. Talvez a solução fosse migrar para a OpenSSL 1.1.x logo, embora sei que a compatibilidade ficaria toda comprometida o que acarretaria um retrabalho hercúleo... Nesse caso, até deveria se pensar na possibilidade oferecer suporte a uma outra lib (quem sabe gnuTLS - que NMHO parece ser mais evoluída e estável...).
Resumindo: Sei que temos problemas nesse sentido, mas estou muito motivado a encontrar alguma solução. Se alguém puder acrescentar alguma informação a respeito disso, tenho certeza de que iremos progredir.
Ah! Por favor, desconsiderem sugestões de "usa winCrypt e etc...", pois o ambiente não se limita ao windows.
Bem! Desculpe pelo tópico extenso e carregado de imagens, mas não consegui ser mais sucinto.
Ps.: Senhores moderadores, confesso que fiquei muito em dúvida sobre onde postar esse tópico. Se esse não for o lugar adequado, sintam-se livres para movê-lo e desculpem-me por isso.