-
Total de ítens
276 -
Registro em
-
Última visita
-
Days Won
2
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Rafael Batiati
-
-
Nunca compilei o projeto em linux; mas os exports não estão indo.
Pode ser por alguma falha nas configurações dos IFDEF do projeto, que não está setando o padrão CDECL corretamente quando roda em linux, ou pode ser alguma configuração do compilador que não está gerando os exports na lib;
Pesquisei rapidamente no google pra ver se alguém tinha um problema semelhante e não achei nada parecido; portanto minha dica fica pra revisar do mais simples pro mais complicado: primeiro reveja as configurações do projeto procurando por algo anormal, depois teste a hipótese dos IFDEF, declarando algum método sem eles:
Por exemplo, abra o ACBrECFDll.pas original e localize a função ECF_Create
Function ECF_Create(var ecfHandle: PECFHandle): Integer; {$IFDEF STDCALL} stdcall; {$ENDIF} {$IFDEF CDECL} cdecl; {$ENDIF} export;
Modifique para essa forma, sem os IFDEF
Function ECF_Create(var ecfHandle: PECFHandle): Integer; cdecl; export;
Compile e veja se você consegue ver o ECF_Create no objdump depois dessa modificação, nisso já teremos uma boa pista de por onde seguir.
-
Código do ACBr e ACBrFramework C# atualizado com a propriedade Margem na classe ConfigBarras
Lembrando que só foi implementado para os ECFs Bematech
Observações importantes:
Segundo o manual, cada unidade equivale a 0.125mm de espaçamento
A margem necessária para centralizar o código de barras vai depender do tamanho e do tipo de código utilizado; é necessário testar cada caso para determinar a margem mais adequada.
Quando a propriedade "ConfigBarras.MostrarCodigo" é definida como True, o texto numérico impresso acima ou abaixo do código de barras não segue o alinhamento definido na propriedade Margem; para centralizar o texto é necessário inserir espaços, exemplo:
acbrECF.ConfigBarras.MostrarCodigo = true; acbrECF.ConfigBarras.Margem = 50; acbrECF.LinhaRelatorioGerencial(" <inter>12345678</inter>");
Qualquer coisa é só falar
Abs!
-
No manual da bematech chama-se "Margem" mesmo ... que é diferente de "alinhamento"
Se fosse simplesmente "alinhamento = Esquerda, Direita, Centro" seria uma maravilha, mas nós temos que passar o espaço de margem que queremos pra distanciar o código da esqueda.
É complicado demais calcular a margem de forma automática para que o código saia centralizado, pois depende do tipo de código utilizado, da largura das barras, da quantidade de dígitos, etc ... se a impressora suportasse o alinhamento como a Sweda seria mais simples.
Você consegue contato direto com alguém do suporte da Epson e Daruma?
-
Oi Daniel,
Eu olhei os manuais.
Na Bematech existe o comando direto para informar a margem; eu alterei e testei com o ACBr e funcionou.
Os outros modelo é que são o problema
Por exemplo, na Daruma e Epson não achei nada parecido no manual; na Sweda existe o parâmetro para centralizar ou alinha à margem
O que acha de eu adicionar a propriedade Margem no ACBrECF.ConfigBarras e inicialmente só implementá-la na classe da Bematech?
Alguma outra sugestão?
-
Pessoal,
Estou precisando centralizar o código de barras impresso no rel gerencial do ECF;
A classe de configuração do código de barras possui parâmetros para altura e largura das barras, mas não tem parâmetros para a margem.
Na DLL da bematech o método ConfiguraCodigoBarras tem um parâmetro para margem, que possibilita essa operação.
Existe alguma forma de fazer a centralização do código ou devo partir para implementar a Margem no ACBrECF.ConfigBarras ?
Alguém sabe se outras ECFs possuem essa mesma função?
Obrigado
-
Pessoal,
Alguém tem alguma experiência pra contar sobre a emissão de serviços no ECF, tributados como ISS, e sua posterior substituição por NFS-e por meio de RPS (recibo provisório de serviço)
Sei que depende muito da lei municipal, alguns município aceitam o próprio cupom fiscal como nota de serviço outros exigem a NFS-e.
No caso de municípios que exigem a NFS-e, é necessário emitir um RPS caso não seja possível emitir a NFS-e online.
As dúvidas são:
O próprio cupom fiscal tem validade de RPS ou é necessário algum tipo de relatório gerencial descrevendo o RPS?
Eu não posso deixar de emitir itens de serviço no ECF já que estou operando com impressão concomitante à venda, certo?
Obrigado a todos
-
Todo o ACBrFramework é via DLL feita com o código original em Delphi; a camada C# e Java é apenas um wrapper para acesso à biblioteca.
Sinta-se à vontade para colaborar, baixe os fontes e veja em qual área suas necessidades se concentram; troque idéias com a turma por aqui para propor novas implementações. Qualquer dúvida é só falar.
Abs
- 1
-
O ACBrFramework.Net está em pé de igualdade nos pacotes ACBrSerial, ACBrPAF, ACBrTEFD, ACBrSpedFiscal e ACBrSintegra; Os pacotes ACBrNFe e ACBrNFSe possuem alguns detalhes técnicos que tornariam mais vantajosa a implementação nativa em .Net à utilização do código atual ACBr em Delphi; Os demais pacotes não possuem implementação ou essa é muito limitada.
Para evoluir esse cenário eu só vejo a necessidade de mais utilizadores/desenvolvedores engajados no projeto.
-
É mais fácil achar os números da mega-sena que achar informação no site da sefaz !!
Alguém está por dentro do processo da NFC-e no estado de Goiás?
Eu vi o decreto em Agosto, com prazo estimado pra Dezembro de 2015, mas até agora parece que não está valendo.
Abs
-
Estou finalizando o desenvolvimento de uma biblioteca 100% em C# que englobará o consumo de todos os serviços em todas as versões disponibilizadas e em para todos os estados. Essa biblioteca será utilizada em produção em um aplicativo de frente de loja para emissão de NFC-e. Também está sendo construído um aplicativo de demonstração em wpf semelhante ao ACBrNFe_demo. Se for de interesse da comunidade nestes quinze dias ela deve ficar pronta, e posso disponibilizar se houver interesse em utilizá-la e me ajudar a mantê-la
Oi Adenilton, seja bem vindo.
Se quiser pode nos mandar o código fonte do jeito que está para analisarmos e trocarmos uma idéia, depois a gente cria um repositório pra ele.
Tenha certeza de que vai multiplicar!
Abs,
- 2
-
Amigo,
Veja os exemplos de uso dos componentes, você não precisa usar as classes Interop diretamente.
Isso vale pra todo o projeto, não só pro CEP, basta você criar um novo componente e chamar o método.
ACBrFramework.CEP.ACBrCEP cep = new CEP.ACBrCEP();cep.BuscarPorCEP("00000-000");Dá uma olhada no fórum sobre o uso do componente CEP, os nomes de métodos/propriedades e forma de uso é 100% compatível com o componente em Delphi.Abs. -
Sim, o NFe não vai ser incluído no ACBrFramework.Net, e a melhor saída pra quem quer usar o ACBr é o ACBrNFeMonitor.
Eu mesmo usei ele via TCP e estou muito satisfeito com o resultado.
(...)
O motivo de não incluir ele no .Net é simplesmente o custo, pois vai dar tanto trabalho pra fazer/usar que é melhor fazer diretamente em C#
Chegamos a iniciar o desenvolvimento dele, mas tivemos problemas com a assinatura digital, uso dos certificados, dependência do CAPICOM para certificado A3, visualização e impressão dos DANFES, e vários outros que apontaram para o abort desse componente.
Nossa vontade é fazer algo parecido com o ACBrNFeMonitor em .Net nativo, só que no momento não temos prioridade nisso, então se algum desenvolvedor quiser tocar o projeto, fique a vontade, contribuiremos no que pudermos ser úteis.
Abs,
-
Cara,
A primeira situação, o registro 60A repete N vezes para cada totalizador do ECF (cada situação tributária), então não há nada de anormal no arquivo ... veja se você está populando o registro corretamente, pois pode ser por aí. Tente fazer um exemplo pequeno, colocando os dados manualmente no componente pra reproduzir isso, se conseguir reproduzir, poste o código aqui.
Já a segunda situação, normalmente ocorre quando você coloca um Path ou nome de arquivo incorreto.
É bobeira, mas muito comum esquecer de terminar o path com um "\", exemplo: "C:\MeusDocumentos\", caso contrário o componente concatena o caminho errado.
E em C# lembre-se, ou você usa string literal com o arroba @"c:\MeusDocumentos\", ou coloca duplo "\\" nos paths, "C:\\MeusDocumentos\\"
Abs
-
Parabéns, você obteve uma resposta muito rápida!
Leia as regras do forum por favor:
- 1
-
Pode detalhar o que está acontecendo?
Problemas comuns:
- Sem a DLL do fabricante no Path
- Caminho do arquivo incorreto
- Parâmetros incorretos
- Uso do emulador
Abs
-
Na autocom, conheci melhor o PDV, e como nosso PDV não está homologado para o PAF, para os outros estados vou estar fazendo a integração com o PDV de vocês.
Mas uma duvida, o código fonte da ACBRFramework32 está sendo escrito em Delphi? se sim ficará difícil de contribuir pois estamos desenvolvendo em C#
Oi Luis, respondendo seu post:
1. A frase "vou estar fazendo a integração com o PDV de vocês" é equivocada, pois o projeto ACBr não é, nem contém um PDV. Ele é um conjunto de componentes para criação de software para automação comercial.
Na autocom, você deve ter conhecido o DJPDV, desenvolvido pela DJSystem do Daniel, o criador do projeto ACBr.
Mas cada colaborador do ACBr trabalha em cidades/nichos diferentes e cada um desenvolve seu próprio produto de automação, tendo como ponto comum apenas a utilização do ACBr.
Em todo caso, se você precisar integrar com um PDV, eu recomendo a DJSystem!!!
2. TODO o ACBr, incluindo o ACBrFramework32.dll é feito em Delphi/Lazarus.
Apenas os projetos referentes à interop é que são desenvolvidos em .Net (ACBrFramework.Net) ou em Java (jACBrFramework)
Vale lembrar que o nosso objetivo com o ACBrFramework é levar o ACBr em Delphi para outras linguagens de programação, aproveitando todo o código já desenvolvido e toda experiência e maturidade já acumulada.
Qualquer dúvida fique a vontade para perguntar
Abraços
- 1
-
Bom dia Luís, seja bem vindo
1 - O endereço acbrframework.sourceforge.net / http://acbr.sourceforge.net - é o mesmo projeto certo?
R: Sim, e não ...
O ACBr é o projeto original voltado para desenvolvedores Delphi e Lazarus (usando os componentes) e para desenvolvedores em outras linguagens (usando o ACBrMonitor e ACBrNFeMonitor)
Enquanto o ACBrFramework é um subprojeto que cria uma camada de Interop permitindo o uso dos componentes ACBr por desenvolvedores em .Net, Java e ActiveX
Ambos os projetos se relacionam e um contribui com o outro. No endereço acbrframework.sourceforge.net hospedamos apenas o site informativo do ACBrFramework. O fórum e SVN é hospedado junto do ACBr
2 - Para estar trabalhando com o ECF, o que realmente utilizar ACBRx, ACBRFramework.Net.dll, ACBRFramework32.dll
(Considerando vb6 como sendo a atual e o novo PDV em C#)
R:
O projeto ACBrFramework deve ser utilizado via ACBrFramework.Net.dll para .Net ou sua versão específica para ActiveX (Veja aqui no fórum na seção de ActiveX e VB6 como usar)
A ACBrFramework32.dll é uma dll nativa feita em Delphi, que não precisa ser utilizada diretamente. Ela faz parte do projeto, e a dll .Net já a contém.
O projeto ACBrX é outro projeto diferente, para saber mais sobre ele acesse http://www.easysoftware.net.br/acbrx.html
3 - Baixei o ACBRFramework.Net, está em C#, percebi que os métodos chamam a ACBRFramework32.dll, Mas quando utilizo no meu projeto uso apenas
a ACBRFramework.Net.dll, A Questão, onde fica o código que se relaciona com as dlls dos Fabricantes dos ECF?.
A Dll .Net contém a dll nativa ACBrFramework32.dll, não é necessário copiá-la na máquina. É nessa DLL que fica todo o código funcional do projeto. O restante é "apenas" para interop;
As dlls de fabricantes precisam ser copiadas para o Path, seja na pasta do Windows\System32 ou junto do seu executável.
Veja também as outras dlls que precisam ser distribuídas, na pasta "Dll" junto do projeto ACBrFramework
4 - Como posso participar na geração dos próximos códigos, sendo que somos uma equipe de 4 desenvolvedores em C# e estamos começando a desenvolver algo para o SAT, penso que posso seguir o padrão ACBR e disponibilizar o que estamos criando aqui na site.
Você pode baixar o código fonte e estudá-los, e participando do fórum você compartilha com outros desenvolvedores suas intenções e idéias sobre o que pretende implementar.
Num primeiro momento, você pode enviar o código fonte para nossa análise e atualização do repositório do SVN.
O acesso de escrita no SVN vem com o tempo, quando o colaborador já está familiarizado com o projeto e padrão de código.
5 - No outro site eu achei mais nesse não, como posso contribuir financeiramente?
Veja o ACBrSAC se quiser contribuir com o projeto.
http://www.projetoacbr.com.br/forum/index.php?/page/SAC/sobre_o_sac.html
O ACBrFramework não participa do fórum do ACBrSAC, então dúvidas e bugs continuam a ser tratadas no fórum aberto para esses usuários.
Mas a grande parte das dúvidas de utilização são comuns aos projetos.
-
Sabe se existe algum aquivo de declaração da dll para o AcbrFrameWork32.dll ?
Pelo que notei, faltam muitas funcoes (novas funcoes) não declaradas no acbr32dll_dec.prg.
Resolvi substituir acbr32.dll por acbrFramework32.dll, tive alguns retornos de erros na hora de declarar...
Obrigado pela dica da descontinuidade.
O uso da DLL nativa no VB6 e Fox também foi descontinuado.
Para você usar o exemplo da ACBr32.dll substituindo pela ACBrFramework32.dll precisaria de algumas coisas:
1 - Atualizar as declarações de funções da DLL Nativa ACBrFramework32.dll para usar no Fox ... nós temos essas declarações em C#, C e Java. Aí vai depender do que for mais fácil pra portar. As declarações em VB6 e xBase (Fox) foram descontinuadas.
2 - Compilar em STDCALL. Hoje ela só compila em CDECL, o modo STDCALL foi descontinuado e a turma do Fox e VB6 não é capaz de usá-la diretamente, pois essas linguagens não suportam outra convenção senão a STDCALL.
(...)
Com certeza vocês devem estar pensando:
Por que raios vocês descontinuaram uma DLL tão bacana assim? O exemplo funcionava legal pra caramba! Nossa vocês são uns malas mesmo!!!
Eu explico:
Chegamos num ponto do projeto onde as funções ficaram mais complexas, situações que retornam e recebem ponteiros, arrays, structs, ponteiros de função, etc. E simplesmente não conseguimos fazer declarações dessas funções compatíveis com VB6 e xBase. Não iria adiantar continuar pois nessas linguagens métodos importantes ficariam de fora.
Então descontinuamos a compilação STDCALL e focamos apenas no CDECL para .Net e Java.
Para quem usa VB6, xBase e outras linguagens, nós temos atualmente a distribuição ActiveX da ACBrFramework.dll, que nada tem a ver com a dll nativa ACBrFramework32.dll ... nessa versão ActiveX trabalhamos com componentes, propriedades, métodos e eventos, enquanto na dll nativa trabalhamos apenas com funções estáticas.
A solução no seu caso é modificar esse exemplo trocando as chamadas da ACBr32.dll para o ActiveX, e fazendo isso as declarações de funções perdem todo o sentido. Por exemplo:
//Onde era função estática int ecfHandle; ECF_Create(&ecfHandle); ECF_Device_SetPorta(ecfHandle, "COM1"); ECF_Ativar(ecfHandle); //Vira chamada ao objeto ecf = CreateObject("ACBrFramework_Net.ACBrECF"); ecf.Device.Porta = "COM1"; ecf.Ativar();
OBS: Exemplo fictício, apenas para se ter uma noção!
Qualquer dúvida, estamos aí.
Abs
-
E onde tem um manual que possa usar para usar as funcoes do activex com ele , vou converter a aplicação para hwgui
Nesse link tem alguma informação sobre como usar o ACBrFramework ActiveX
As funções existentes no componente seguem os mesmos nomes dos métodos/propriedades do ACBr, e o próprio ActiveX possui algo como como auto-completar.
Agora vai depender de como colocar isso dentro do xHarbour.
Qualquer coisa posta aí o resultado pra gente.
Abs
-
se esta informação proceder você pode utilizar a dll do acbrframework.net com cominterop ou pode usar a dll nativa diretamente o que no meu ponto de vista daria mais trabalho.
Eu não recomendo mais o uso da DLL nativa no DBase, Fox, Harbour, etc ...
Isso por que temos várias funções que retornam structs, arrays, ponteiros, e outras estruturas de dados que essas linguagens não suportam.
Uma solução é usar como ActiveX, como o Rafael Dias falou acima.
... Ou ...
Ou implementar no ACBrFramework versões alternativas dessas funções que retorne/receba strings formatadas ao invés de array e structs, +- como é a interface TCP do ACBrMonitor.
Como isso daria um bom trabalho pra fazer, acredito que o uso do ACBrMonitor é mais vantajoso.
- 1
-
Então é + ou - isso aqui:
Você usa seu objeto ead e adiciona um novo listener a ele:
ead.addOnGetChavePublica(new ACBrEventListener<ChaveEventObject>() { @Override public void notification(ChaveEventObject e) { e.SetChave("XXXXXXXXXXXXXXXXXXXXX" + "\n" + "YYYYYYYYYYYYYYYYYYYYY" + "\n" "..."); } } );
Esse listener esperado no método addOnGetChavePublica é só uma implementação da classe ACBrEventListener<ChaveEventObject> que contém o método abstrato notification onde o conteúdo da chave será retornado.
No exemplo acima, implementamos como uma classe anônima, bastante comum em eventos no java.
Não se esqueça de passar o conteúdo da sua chave, e não o caminho do arquivo.
E inclua as quebras de linha, exatamente onde elas estão, pois o ACBr precisa delas.
Abraços.
-
Tenho interesse! Como fazemos?
Então, vamos lá:
O projeto é originalmente feito em .Net, e usamos uma camada para compatibilizar e expor as classes de .Net para ActiveX, através de um processo chamado COM Interop. Assim qualquer linguagem que use ActiveX poderão acessá-las.
Primeiro de tudo, baixe os fontes, a DLL e os exemplos:
DLL compilada do ACBrFramework.Net.COM
http://sourceforge.n...OM.zip/download
Fontes:
http://acbrframework...s/codigo-fonte/
Você precisará do Visual Studio para abrir e compilar o projeto ACBrFramework.Net, pode baixar a última versão do Visual Studio Express no site da Microsoft, é gratuito e funciona muito bem.
Um bom começo é você usar o exemplo em VB6 que já existe pra entender o funcionamento do componente, depois olhar o código-fonte do componente ACBrECF no Visual Studio.
Nesse link abaixo, você encontrará uma breve introdução a como usar/compilar o ACBrFramework para COM Interop.
(...)
Como você verá no código fonte, nós introduzimos alguns atributos à declaração das classes visíveis no ActiveX
[ComVisible(true)] [Guid("7F5440D4-8D62-441B-9251-E911437D5F8F")] [ComSourceInterfaces(typeof(IACBrECFEvents))] [ClassInterface(ClassInterfaceType.AutoDual)] public class ACBrECF ...
Precisamos mudar também os seguintes recursos:
- Eventos: no ActiveX são diferentes e precisam de bastante alterações (criação de uma interface e mudança nos delegates);
- Dados Decimal: no ActiveX é Currency e precisam de um atributo especial;
- Tipos usando Generics: no ActiveX não tem equivalente, e precisam de uma classe específica no .Net;
- Overloads: no ActiveX não tem equivalente e precisam ser substituídos por parâmetros opicionais;
(...)
Essas mudanças você pode conferir nos componentes que já fizemos: ACBrECF, ACBrAAC, ACBrEAD e ACBrDIS (para displays).
Existe uma diretiva de compilação #if COM_INTEROP que possibilita aplicar essas modificações apenas numa versão especial da DLL compilada para ser usada com o ActiveX. Na versão sem COM_INTEROP a DLL é feita para ser usada no .Net apenas.
Para o mínimo necessário ao PAF, precisamos aplicar as mesmas mudanças nos componentes ACBrPAF, ACBrSped e ACBrSintegra.
O TEF também é necessário para o PAF-ECF, e o ACBr possui o componente ACBrTEFD, mas alguns desenvolvedores implementam os TEF por outros meios.
Depois com o tempo vamos incluindo os demais componentes da paleta de componentes do ACBrFramework.Net (ACBrCEP, ACBrCNIEE, ACBrIBGE, ACBrBAL, ACBrLCB, ACBrRFD, ACBrSMS e ACBrValidador) .
(...)
Dá uma lida geral aí em tudo, olha os exemplos, veja se o componente te atende.
Depois a gente vai se falando sobre dúvidas e como ir fazendo as alterações.
Abraços.
-
Não, para ActiveX só existe os componentes ECF (para manipular os ECFs), AAC (para o arquivo auxiliar criptografado) e EAD (para assinatura digital).
Para o PAF-ECF completo você precisaria dos componentes PAF (para gerar os arquivos do menu fiscal), Sintegra e Sped (para o arquivo de vendas por período).
Estes últimos já estão funcionando no ACBrFramework.Net mas ainda não foram migrados para VB6. Caso você tenha interesse em colaborar, podemos ir conversando.
Abs.
-
Renato, seja bem vindo!
Assim como você eu já passei por tudo isso ... e temos alguns cenários no universo do ACBr
1. Componentes ACBrComum, ACBrSerial, ACBrPAF, ACBrSped, ACBrSintegra, e outros.
Esses componentes são vitais para o PAF-ECF e foram o alvo do ACBrFramework.
Hoje eles funcionam em .Net perfeitamente, e temos projetos levando-os para Java e ActiveX.
Eu particularmente não vejo vantagem numa migração 100% para .Net desses componentes, seria um trabalho gigante reescrever e debugar as mesmas funcionalidades que hoje já temos muito maduras e funcionando bem. Além de perdermos com correções e evoluções feitas pela comunidade em Delphi.
2. Componentes NFe e NFSe
Esses dois componentes ganhariam muito se reescritos nativamente no .Net.
Primeiro pela facilidade em se trabalhar com a criptografia e XML do .Net, e depois por causa da complexidade do projeto, impressão e visualização nativa, etc.
3. NFeMonitor
Como tinha pressa, eu acabei usando o ACBrNFeMonitor em minha aplicação, e desenvolvi um client em C# que protocola via TCP/IP com ele.
Funcionou muito bem e pude usar os PDFs para visualização e impressão dos Danfes.
(...)
E fique tranquilo, não está ofendendo absolutamente ninguém, aliás está sendo muito bem vindo.
Diga aí qual a sua idéia em relação a esse port, e com certeza nós estaremos juntos aí pra contribuir no que for possível.
Abs
Casos de Sucesso com ACBr
em Dúvidas Gerais sobre o ACBr
Postado
Minha segunda homologação com o ACBrFramework.net na Polimig RJ
MultiVendas PDV
Linguagem C# .Net
especificação 02.02
ACBrECF, ACBrPAF, ACBrSpedFiscal, ACBrSintegra, ACBrAAC e ACBrEAD
Mais uma vez deixo aqui meus agradecimentos a todos da comunidade ACBr, sucesso!