jACBRframework

[vasilvei]

Sim, ainda tenho que implementar mais algumas funções na JNI, para a minha homologação do PAF, assim tiver proto eu te aviso.

Abraço.

[vasilvei]

Cara to fazendo aqui epelhoMFD e tals ta feito no c++, e jacbr, porém quando eu chamo ele dá esse erro:

"Erro ao carregar a função:EPSON_Obter_Dados_MF_MFD de: InterfaceEpson.dll"

eu uso uma ECF Epson TM-T81F

[Rafael Batiati]

Cara to fazendo aqui epelhoMFD e tals ta feito no c++, e jacbr, porém quando eu chamo ele dá esse erro:

"Erro ao carregar a função:EPSON_Obter_Dados_MF_MFD de: InterfaceEpson.dll"

eu uso uma ECF Epson TM-T81F

Infelizmente não há protocolo nos ECFs que permita implementar isso via comunicação direta.

Todas as funções MFD necessitam das DLLs do fabricante

No diretório do ACBr no SVN (no ACBr, e não no ACBrFramework) há uma pasta "DLLs\ECF" onde estão todas as DLLs dos fabricantes.

Você precisa posicionar a DLL do fabricante do seu ECF, no caso a Epson, no seu path, junto da ACBrFramework32.dll.

***

Inclusive, deixa eu levantar uma questão aqui ... justamente por essa dependência da dll do fabricante para o MDF,

o ACBrFramework e o próprio aplicativo PAF continuam limitados à plataforma da dll do fabricante.

Por exemplo, não é possível rodar o jACBrFramework em uma JVM 64 bits nem compilar o ACBrFramework para 64bits pois a DLL de 32bits do fabricante não será carregada corretamente ao emitir uma leitura MFD. Todo o resto funciona, exceto essa dependência.

Abs!

[Rafael Dias]

@Batiati

Depende do fabricante no caso da Daruma ela possui tanto 32 bits como 64 bits.

E tbm versões para linux.

Então é basicamente isso vai depender do fabricante, mas no geral é basicamente so win 32bits.

[vasilvei]

Bom dia Rafael.

Só basta colocar a dll no diretório?

[Rafael Batiati]

Bom dia Rafael.

Só basta colocar a dll no diretório?

Sim, colocar a dll no mesmo diretório junto da ACBrFramework32.dll.

[vasilvei]

Eu coloquei a dll lá e deu certo

eu passo:

Ecf.pafMFMFDEspelho(dtInicialDb, dtFinalDb, "C:\\Arena\\EspelhoMFD\\DATA\\" );

ele gera o arquivo certo porém dá essa msg:

Erro ao copiar C:\Arena\EspelhoMFD\DATA\ACBr_ESP.txt

para C:\Arena\EspelhoMFC\DATA\

mas o arquivo esta lá...

por que dá esse erro?

[vasilvei]

Boa tarde Rafael eu vi que tem no projeto JacrbrFramework c++, as .h:

 

ACBrPAF.h 

ACBrEAD.h

...

 

no caso se eu quiser usar no java eu devo fazer:

 

Criar um JACBrPAF.cpp

e um JACBrPAF.h

 

e mesmo para EAD, ou dar um include das ACBrPAF.h, ACBrEAD.h no JACBrECF.h?

 

qual a forma correta?

[Rafael Dias]

A forma correta é criar um JACBrPAF.cpp.

[vasilvei]

Beleza!

 

outra duvida?

 

 

DllImport int ECF_PafMF_LMFS_Espelho(const INTPTR ecfHandle, const double DataInicial, const double DataFinal, const PCHAR CaminhoArquivo);

DllImport int ECF_PafMF_LMFS_Espelho_CRZ(const INTPTR ecfHandle, const int CRZInicial, const int CRZFinal, const PCHAR CaminhoArquivo);

 

eles já gerar o EAD no final do arquivo automaticamente?

[Rafael Dias]

Sim, mas apenas se o EAD estiver setado no ECF e estiver com a chave privada dele setada corretamente no evento,

Caso contrario vc tem q mandar assinar manualmente.

[vasilvei]

Boa tarde tem esse médoto  

 

public native void estornaPagamento(String codFormaPagtoEstornar, String codFormaPagtoEfetivar, double valor, String observacao) throws ACBrException;

 

porém ele não esta implementado para a ECF epson, como eu faço para implementar ele?

[Rafael Batiati]

Oi vasilvei,

Isso é implementação dentro do ACBr e não do ACBrFramework, na classe  ACBrECFEpson.

 

Olhei a classe e ela realmente não tem esse método, e normalmente isso ocorre para algum modelo de ECF específico é porquê ele não dá suporte para a ação.

Procure ver se é possível realmente realizar essa operação num Epson, aí abra um outro tópico específico disso que a turma que desenvolve os ECFs poderá te ajudar.

 

Abs!

[vasilvei]

Valeu Rafael pela resposta, deixar eu te explicar o meu problema:

 

Eu estou fazendo o TEF, e tem uma rotina de homologação que devo deixar somente papel na ecf para quando estiver imprimindo o comprovante do TEF(o cupom vinculado), acabe o papel, eu devo substituir o papel, e mandar reemprimir o cupom vinculado, porém quando eu faço isso ele diz 0E0B - Meio de pagamento não encontrado., e é o mesmo dados que estou passando para imprimir que passei naquele que faltou o papel.

 

eu entendi que dá esse erro porque o valor e o coo que estou passando, já foi imprimido o CV. É por esse motivo que dá esse erro o qual seria o motivo?

 

como eu poderia resolver o meu problema? 

[Rafael Batiati]

Sim, nesse teste é usado relatório gerencial e não vinculado, pois o vinculado como você mesmo disse, já foi impresso e só pode ser aberto uma vez.

 

Para o TEF toda reimpressão deve acontecer via relatório gerencial.

Abs,

[bienemann]

Estou estudado c++ para colaborar com o projeto, e incrementar algumas necessidades.

 

Instalei o visual C++ e abri o projeto ACBrFramework_JNI, ao abrir o projeto me deparei com o seguinte "erro cannot open source file jni.h" que indica a falta desse arquivo de cabeçalho no projeto.

 

Onde posso achar esse arquivo ou como resolvo esse problema.

[Rafael Dias]

Como ja foi dito anteriormente

 

Legal, vejo que estamos indo bem!
Vamos lá:



Você precisa setar o caminho do seu JDK, onde fica instalado o Java.
O compilador vai usar o jni.h e o linker vai usar o jvm.lib

No VS fica assim: Vá em propriedades do projeto, clique em "C/C++" e indique o caminho do include

jni_1.JPG

Depois clique em "Linker", "Input" e indique o caminho do jvm.lib

jni_2.JPG

Esses arquivos ficam sempre no diretório de instalação do JDK.

(...)



Sim, você pode compilar em 64bits; Mas note que pra fazer isso, você precisará referenciar a lib 64bits e o ACBrFramework64.dll.
No Java, também será necessário carregar o JNI correto, dependendo da plataforma, hoje é feito somente isso:

//Carrega a biblioteca de chamadas nativas JNI
System.loadLibrary("ACBrFramework_JNI");

Java 7 vai funcionar, qualquer versão igual ou superior ao JDK que você usou pra compilar o JNI vai funcionar.

(...)



As funções disponíveis no ACBrFramework estão todas declaradas nos arquivos .h.
Enquanto na DLL as funções são estáticas, na classe Java temos os métodos declarados da forma OO, como classes que modelam o comportamento dos componentes o mais próximo possível do ACBr Delphi, para que possamos nos beneficiar dos exemplos, foruns, documentações, etc.
O jACBrFramework só faz chamadas ao que está implementado no JNI, que por sua vez foi exposto do componente ACBr.

(...)



Revisei os posts antigos, e não tem código-fonte em anexo.
Mas eu convido todos vocês interessados a participar aqui do fórum, e da evolução do jACBrFramework. Estou disponível para ajudar sempre.

Abs!

 

[bienemann]

Como foi gerado automaticamente os arquivos de cabeçalho referente a comunicação com biblioteca ACBrFramework.dll, como é feita a comunicação com a mesma e qual a versão do Lazarus utilizada?

 

Já trabalho com esse projeto no windows e agora quero trabalhar com o mesmo em linux, estou fazendo os teste com o ubuntu 12.04 e utilizando o QT para gerar a biblioteca de comunicação JNI.

 

 

Muito obrigado pela atenção!!!

[Rafael Batiati]

Como foi gerado automaticamente os arquivos de cabeçalho referente a comunicação com biblioteca ACBrFramework.dll, como é feita a comunicação com a mesma e qual a versão do Lazarus utilizada?

 

Os arquivos de cabeçalho são gerados por uma ferramenta que nós "inventamos", o ACBrDefExporter (ACBrFramework.Net\ACBrDefExporter). Ele pega as APIs declaradas em C# e converte para C/C++ ou Visual Basic, nos poupando trabalho de manter essas versões, uma vez que a versão .Net é quase sempre a mais atual.

 

Uma vez gerados os .h, a DLL pode ser linkada no código JNI a partir de uma .lib exportada por um utilitário chamado DumpBin (ACBrFramework\cLIB).

 

A versão do Lazarus que uso foi a última disponível quando fiz download 1.0.4.

 

Abs

[bienemann]

E com relação ao uso do ACBrFramework em linux. Já tem alguma iniciativa?

[Rafael Batiati]

E com relação ao uso do ACBrFramework em linux. Já tem alguma iniciativa?

 

Iniciativa já temos, só não temos "acabativa" por enquanto ... rsrsr

 

Seguem as iniciativas:

 

- O ACBrFramework compila normalmente em Lazarus no Linux e todas as chamadas são em compatíveis com Linux (cdecl ao invés de stdcall).

- O código do JNI apesar de ser um projeto em Visual C++ foi feito pra ser compilado em gcc também. Compatível com qualquer plataforma Java.

- O ACBrFramework.Net também foi feito pensando pra rodar no Mono, usando o ACBrFramework.so

 

Dessa forma só precisamos mesmo é seguir o caminho pra botar pra funcionar.

Eu não tenho muito contato nem habilidade com o Linux, mas estou disposto a ajudar no que estiver a meu alcance.

Abs,

[bienemann]

Ok, estou preparando uma maquina com o ubuntu 12.04 32 e 64 Bits com o lazarus e com o QT5 para compilar o JNI. Estou iniciando alguns testes...

 

Obrigado.

[bienemann]

Novas para o projeto, estou terminando de implementar geração de arquivo de carga a comunicação direta com balanças em JAVA. Quero saber qual o procedimento para envio do código para contribuir com projeto.

[Rafael Batiati]

Oi Brian,

 

Qual componente você está implementando?

As contribuições para o projeto são feitas através da participação no fórum e envio dos códigos-fontes.

 

Nos projetos da família ACBrFramework nós incluímos apenas os componentes baseados em interop com o ACBr, e os códigos-fonte podem ser enviados aqui pelo fórum. Nós seguimos um padrão de código estabelecido durante o desenvolvimento, para assegurar que as manutenções e evoluções possam ser feitas por qualquer pessoa, por isso é importante a comunicação entre os colaboradores.

 

Projetos e componentes que não fazem parte do ACBr não são o foco do ACBrFramework, mas podem ser incorporados ao repositório do ACBr em outra seção se os administradores acharem interessante.

 

(...)

 

Tivemos mudanças recentes no projeto, você pode ler sobre isso nesse outro post:

 

 

Inclusive estamos discutindo mudanças de arquitetura do projeto jACBrFramework para substituirmos as chamadas JNI escritas em C++ por JNA escritas diretamente em Java.

Caso tenha interesse, vale a pena dar uma lida;

 

Abraços.

[bienemann]

Como disse o que implementei foi o projeto jACBrFramework para a comunicação direta(Serial) com as balanças escrito em JAVA utilizando o projeto RXTX e a geração dos arquivos txts para dar carga de dados nas balanças de retaguarda. Dessa mesma forma quero implementar a geração dos arquivos do PAF(R, P, Sintegra, SPED e etc) escrito em JAVA. 

 

Nosso sistema está utilizando o projeto antigo (jACBr). Quero muda-lo para o jACBrFramework já com essas funcionalidades tanto das balanças quanto dos aquivos do PAF.

 

Agora vou baixar as atualização para adequar o código a mesma estrutura do jACBrFramework.

Editado 21 Fevereiro, 2013 por bienemann