Rafael Batiati

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!

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

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. http://aplicacao.sefaz.go.gov.br/index.php/post/ver/182843/decreto-regulamenta-nota-eletronica-do-consumidor Abs

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,

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: https://www.google.com/url?q=http://www.projetoacbr.com.br/forum/index.php%3F/forum-16/announcement-1-sim-n%25C3%25B3s-temos-regras/&sa=U&ei=Ed3xUYjoKoOG9gSTuIEY&ved=0CAcQFjAA&client=internal-uds-cse&usg=AFQjCNFf2UTyQFhEYzS2LiRBoWaPT6PFZw

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

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

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.

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

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

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.

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.

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