Ir para conteúdo
  • Cadastre-se

wrmedeiros

Membros
  • Total de ítens

    225
  • Registro em

  • Última visita

  • Days Won

    1

Tudo que wrmedeiros postou

  1. Obrigado @Daniel Simoes ! Foi o que falei para um colega, o mais seguro é comprar a TM-20 ou os modelos Bematech e Daruma que já sabemos que funciona. Sabem informar se essa Tanca funciona? http://www.automacaototal.com.br/impressoras/impressora-tanca-tp-650-usb-serial Pelo que pesquisei, o SAT funciona com ela, mas e NFC-e?
  2. Senhores, Alguém já testou a impressora não-fiscal Epson TM T-88V com o ACBrMonitor? (usando ESC/POS) Fiz algumas buscas no fórum, e não encontrei nenhuma referência para esse modelo. Fiz algumas buscas no site do fabricante, e aparentemente a impressora suporta ESC/POS: https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=83 Epson TM T-20 creio ser a melhor escolha (pensando no ACBr), mas só queria confirmar se esse outro modelo também funciona, pois vez ou outra não encontramos a TM-20. Lembrando que pretendo usar ESC/POS (não quero usar gerador de relatório).
  3. Que bom que ajudou @yan ! Mas creio que todas essas alterações que fiz (já faz mais de 1 ano acredito) já estão no trunk2 não? Lembro que na época o @Régys Silveira fez umas melhorias no meu código e commitou.
  4. Obrigado @Daniel Simoes ! Vou testar e aviso para vocês.
  5. Pode sim @AllanFC ! É exatamente o que ocorre comigo! Via CAPICOM funciona perfeitamente. O problema de usar CAPICOM é que você vai ficar preso ao Windows, e nossa ideia em usar o ACBrMonitor é permitir o PDV no Linux.
  6. Estou com algumas outras broncas urgentes aqui e não vou ter como continuar os testes, mas desconfio disso: ATENÇÃO: Chave RSA Privada NÃO pode ser lida no arquivo "swh.ini". No nosso outro sistema (Delphi usando o componente em vez do Monitor) lembro de ter configurado a chave RSA no componente de assinatura (ACBrEAD acho). Vou dar uma busca nos fóruns para ver como configura isso no swh.ini e reporto pra vocês. O estranho é o motivo do OpenSSL funcionar com certificados da Certsign e não funcionar com Soluti.. se fosse falta dessa chave RSA deveria falhar nos 2.
  7. Segue os 2 arquivos. Um feito com OpenSSL (falha), outro com CAPICOM (OK). O sistema automaticamente incrementa o número da nota, mas os itens são os mesmos... Basicamente eu abri o ACBrMonitor, defini como "OpenSSL", fui no PDV e mandei emitir. O erro surgiu, copiei o XML. Fui novamente no ACBrMonitor, mudei para "CAPICOM", e mandei emitir novamente, deu certo, e por fim copiei o XML. CAPICOM_OK_13160606183532000198650010000070021000070005-nfe.xml OPENSSL_ERRO_13160606183532000198650010000070011000070008-nfe.xml
  8. Entendi @Régys Silveira ! Eu fiz a instalação, e funciona bem com CAPICOM, o problema ocorre quando usando OpenSSL. O instalador deles é só Windows, e pretendo usar o sistema principalmente no Linux, e lá só terei o OpenSSL disponível. Estou devendo os 2 xmls que André pediu... vou gerar e envio.
  9. Chegar em casa eu providencio. Adianto que acho pouco provável ser problema de XML, pois eu só altero de OpenSSL para CAPICOM no ACBrMonitor e o sistema consegue emitir.
  10. Senhores, bom dia. Teria algum problema se eu migrasse esse tópico para o fórum aberto? Creio que mais pessoas tendo acesso ao problema será mais fácil achar uma solução.
  11. Precisa sim @Juliomar Marchetti ! E as instalei, tanto que funciona perfeitamente via CAPICOM (que usa os certificados/cadeias instalados no IE); A pergunta é, como instalar as cadeias quando usando OpenSSL? Pois ele não usa os certificados/cadeias que estão instalados no IE, e via ACBrMonitor informo apenas o path do pfx e senha. Acredito que o certificado da Certsign funciona via OpenSSL pois o ROOT CA é conhecido pelo OpenSSL (observe que no IE já vem "de fábrica" vários root's CA´s configurados, tais como GlobalSign, Verisign, etc.), já no caso da SOLUTI, pelo que vi o ROOT CA é a ICP Brasil, e certamente não vem na lista de root´s ca´s do OpenSSL. #Chute
  12. @Juliomar Marchetti bem que eu desconfiei que o design do aplicativo no meu notebook pessoal estava bem diferente do instalado no notebook da empresa Na empresa eu estou usando o 03.03.5, em casa por descuido instalei uma versão mais velha. De qualquer forma, desinstalei a versão velha, instalei a nova, e o mesmo problema ocorre.
  13. Boa tarde. Uso CAPICOM no Delphi para NFC-e, como também CAPICOM no ACBrMonitor para uma outra aplicação que estamos desenvolvendo em Java e funciona muito bem. Um outro desenvolvedor configurou o ACBrMonitor para usar OpenSSL, selecionou o PFX (certificado A1 da SOLUTI), senha, etc. e tentou emitor o NFCe, o ACBrMonitor retornou a seguinte mensagem: XMotivo=Rejeicao: Falha no reconhecimento da autoria ou integridade do arquivo digital Fui no ACBrMonitor, mudei de OpenSSL para CAPICOM, tentei emitir o mesmo NFC-e, e funcionou (ou seja, não é erro de XML, namespace, etc. como ocorreu em outros tópicos que relatam esse problema). Fizemos uma outra NFC-e com os mesmos itens, mas dessa vez usamos um certificado de outra empresa (CertSign), e ajustamos a configuração para OpenSSL, funcionou. Em resumo: Certificados CertSign funcionaram com OpenSSL e CAPICOM Certificados SOLUTI funcionaram com CAPICOM e falharam com OpenSSL ("falha no reconhecimento de autoria"). Creio não ser um problema no ACBrMonitor, e sim algo mais baixo nível (talvez o ACBrNFe ou até mesmo algum ajuste na configuração do OpenSSL, tal como "cadeias de certificado", etc.). Estou preparando o ambiente para debugar melhor o ACBrMonitor via Lazarus, mas decidi postar para que os amigos possam dar alguma opinião sobre o tema, pois como sabemos o CAPICOM funciona relativamente bem, mas não é multiplataforma e pelo que li a Microsoft não tem lançado mais atualizações pra ele. Versão do ACBrMonitor: ACBrMonitorPLUS 0.1.11.4 SO: Windows 7 x64
  14. wrmedeiros

    ACBrFramework

    Bom dia Alexandre. Fiz várias buscas, e descobri que trata-se de um bug no FPC pra Linux. Abri um tópico no grupo de Lazarus, e após vários testes descobrimos que as funções só conseguem ser exportadas no Linux quando a declaração export fica dentro do lpr (arquivo de projeto). Se colocar o export da função em um .pas, não exporta. Fiz um projeto de exemplo, coloquei o export dentro do pas, não funcionou. Em seguida movi o export para o lpr, funcionou, segue exemplo: https://github.com/welkson/TesteFPC O problema é que peguei o projeto do ACBr, selecionei uma unit para testar (se não me engano ACBrECF_DLL), removi o export da unit, joguei no .lpr, gerei o .so, e após testar com readelf o problema persiste (não exporta a função). Essa semana está um pouco corrida, e não tive tempo de continuar os testes, mas minha intenção é comentar no lpr a importação de todas as uses do ACBr, em seguida habilitar apenas 1, e tentar trabalhar nas funções pra ver qual o motivo das mesmas não estarem sendo exportadas. Qualquer ajuda será bem vinda. Abraço,
  15. Fiz um demo [1], testei pelo Windows (via Dependency Walker), funcionou perfeitamente (a função "Teste" aparece na lista de symbols). No Linux, usando o mesmo código, mesma versão do FPC + Lazarus, não funciona (via "nm", "readelf" ou "objdump", a função Teste não é exibida). Da forma como está hoje, o ACBrFramework não funciona no Linux. Estou lendo sobre exportação de símbolos no FPC, mas se alguém souber algo que possa ajudar, agradeço.
  16. Fiz o teste na 1.4.2, mesmo problema.
  17. Abri meu Lazarus no Windows e no Linux, conferi cada configuração do projeto, tudo igual. Verificando a versão, percebi que no Windows estou usando Lazarus 1.4.2, e no Linux 1.4.0 (o FPC é o mesmo nos 2 sistemas). Acredito que se a versão do FPC fosse diferente, poderia influenciar... mas o Lazarus provavelmente não. Na dúvida, estou desinstalando o Lazarus, e vou tentar instalar o 1.4.2. Quando concluir os testes posto os resultados.
  18. Olá Rafael, Eu já havia feito esse teste, não exporta a função (até porque, mesmo no Windows o projeto também usa CDECL). Fiz a pergunta no fórum do Lazarus, mas também não obtive resposta. Será que o pessoal está usando o jACBrFramework apenas no Windows?
  19. wrmedeiros

    ACBrFramework

    Boa noite Mauro. Como disse no post anterior, consegui gerar nas 2 plataformas, no entanto, só no Windows funciona... no Linux o .so não tem as funções (o Lazarus por algum motivo não exporta). Estou tratando isso nesse post:
  20. Eu acredito que o erro no Java está correto, realmente não existe essa função ECF_Create no .so. Gerei a DLL on Windows, usei o Dependence Walker [1] para debugar, e o mesmo mostra todas as funções (ou seja, foram exportadas corretamente). No Linux, usando a mesma revisão, sistema x86, gero o .so, listo as funções usando "nm", objdump, readelf, e em nenhum desses aparece as funções (ou seja, por algum motivo no Linux elas não estão sendo exportadas). Vejam os screenshots no anexo. As diretivas de compilação do projeto no Linux estão no "default" (ou seja, o padrão que o ACBr usa). O que estou fazendo errado? [1] http://www.dependencywalker.com/
  21. No Windows, usando os mesmos repositórios, fiz testes gerando a biblioteca x86 (JDK x86 também), funcionou. Tem algum procedimento diferente para gerar o .so no Linux?
  22. Mesmo problema informado nesse tópico: http://www.projetoacbr.com.br/forum/topic/13955-dúvidas/#comment-84962
  23. No fórum não tem quase nada sobre essa lib... Por exemplo, preparei uma VM com Ubuntu x64, instalei Lazarus, Java, etc. tudo x64... consegui gerar o .so, fui testar no Java, e nunca funcionava (erro no método ECF_Create), depois de muito teste, achei em um tópico alguém comentado que x64 não funcionava. Tentei gerar o .so com x86, mas o FPC não suportava... como era um ambiente de testes, reinstalei todo o sistema operacional com x86, gerei o .so, testei no Java, mesmo erro (ECF_Create)... fiz um svn up no no framework, tinha algumas mudanças, tentei compilar pelo Lazarus uma nova .so, e o projeto reclamou de algumas libs novas do ACBr em Pascal... fiz o svn up no pascal, nada novo... pensei, eles devem está usando trunk2, baixei o trunk2, quando fui compilar está tudo quebrado no projeto do Lazarus (corrigi alguns path's como ACBrEAD, mas já apareceu muitos outros, etc.)... em resumo, acredito que estejam usando o "trunk" (antigo) em vez do trunk2. Fiz o seguinte: Repositório JACBrFramework: atualizado (commit dia 03/08/2015 - inclusão do LFD) Repositório: ACBr (última revisão do "trunk" - como falei, aparentemente o projeto Lazarus não está preparado para trunk2) Quando tentei gerar o .so, ele reclamou que não encontrava o *LFD.pas, como não vou usar agora, e estou apenas testando, comentei a importação da unit e o .so foi gerado corretamente (CDECL x86). Copieo a lib para /usr/lib, tentei usar o demo do jACBrFramework para Java, e obtive esse erro: Exception in thread "main" java.lang.UnsatisfiedLinkError: Error looking up function 'ECF_Create': /usr/lib/libACBrFramework32.so: undefined symbol: ECF_Create at com.sun.jna.Function.<init>(Function.java:179) at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:391) at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:371) at com.sun.jna.Library$Handler.invoke(Library.java:205) at com.sun.jna.Native$4.invoke(Native.java:857) at com.sun.proxy.$Proxy0.ECF_Create(Unknown Source) at jACBrFramework.serial.ecf.ACBrECF.onInitialize(ACBrECF.java:2832) at jACBrFramework.ACBrClass.<init>(ACBrClass.java:9) at jACBrFramework.serial.ecf.ACBrECF.<init>(ACBrECF.java:69) at jACBrFramework.Test.Program.main(Program.java:54) Java Result: 1 BUILD SUCCESSFUL (total time: 8 seconds)
  24. wrmedeiros

    ACBrFramework

    Boa tarde Mauro. Vendo o changelog percebi que o pessoal migrou de JNI para JNA, então não é mais necessário usar o C pra gerar os wrappers. Baixei o código pelo SVN, fiz os testes pelo Windows e pelo Linux, consegui gerar a biblioteca sem erros (.dll / .so). Obrigado.
  25. wrmedeiros

    ACBrFramework

    Boa noite Mauro Eu conheço o projeto (jposbr), mas como você comentou, o projeto ainda está engatinhando. Minha intenção é também usá-lo e contribuir na medida do possível, mas o coordenador do projeto gostou da ideia de aproveitar o código do Delphi/Lazarus no Java (jACBrFramework), e temos uma certa urgência em terminar esse projeto. Já fizemos diversos testes (balanças, impressoras fiscais, leitores de códigos de barras, tef, etc.), mas gostaríamos de entender melhor o processo de gerar a DLL/SO, criar a interface no C (wrapper), usar no Java, etc. Pra piorar, devido esse problema no repositório do SF estou sem acesso ao código que gera a DLL, wrapper em C, etc. O Rafael Batiati ainda está a frente desse projeto?
×
×
  • 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.

The popup will be closed in 10 segundos...