Daniel Simoes

A nova Bematech MP4200 não usa o protocolo ecfBematech e sim o novo protocolo definido no convênio 09/09... use o modelo ecfEscECF

Oi Alexandro, Desculpe-me por só agora entrar em contato.... Parece que você está fazendo um ótimo trabalho de analise e correção... por isso deixo você tentar mais um pouco Se precisar de alguma ajuda estarei mais atento nos próximos dias

Acho que sei do que se trata... Conversei com o Amarildo na FENACOM, ele estendeu o modelo ecfNaoFiscal para permitir o uso do mesmo com a NFCe... Estou trabalhando nisso, com o SAT e NFCe... Amarildo, muito obrigado pela sua contribuição... vou analisar e volto a postar...

O ACBrECF já tem métodos para gerar CAT52 e AtoCotepe1704 CAT52 só pode ser gerada se você estiver gerando o arquivo manualmente... isso é particularmente útil se você está gerando o arquivo a partir do seu Banco de Dados, o que é muito mais rápido e garante sempre a identificação do cliente AtoCotepe1704 deve necessariamente ser gerada pela DLL... (está na lei)... Ele irá ler as informações da MFD do ECF Não há problemas identificar o cliente no final do cupom... desde que o ECF suporte essa característica... Use ACBrECF1.IdentificaConsumidorRodape: Boolean para saber se o ECF tem essa característica. Se o ECF suportar, use: ACBrECF1.IdentificaConsumidor( CPF, NOME, ENDERECO ); antes de subtotalizar ou fechar o cupom

ACBrECF.EnviaComando( #27 + 'v' + #100 ) // enviando comando com 100 milisegundos

Tudo indica que você está usando uma DLL antiga... a Bematech modificou recentemente a maneira de nomear esse arquivo...

Eu ainda não testei o ACBrCTe no Linux, mas sim o ACBrNFe, que usa praticamente as mesmas bibliotecas... Aqui uso um Linux Mageia 2 32 bits Lazarus versão do SVN, e FPC 2.7.1 (baixado pelo SVN)

Já viu o Demo da pasta: C:\ACBr\Exemplos\ACBrETQ\Delphi ??

Obrigado pela colaboração... Vou analisar os fontes em breve...

Apliquei um amplo refactoring no componente ACBrConsultaCNPJ, pois o mesmo reescrevia alguns métodos que a classe mãe (ACBrSocket) já possuía... O motivo principal era que a consulta não estava funcionando em Linux, provavelmente devido a problemas de conversão de UTF8 e Ansi. A classe ACBrSocket já possuía tratamentos para converter UTF8 de e para Ansi, quando necessário... Também otimizei um pouco a rotina de captura dos campos do HTML.. A leitura do CNAE Principal e CNAE Secundário foi implementada

Parece que o problema é incompatibilidade da libxmlsec com Linux 64 bits... Não há solução para isso até o momento...

Fiz um pequeno ajuste para compatibilizar o componente com Lazarus, Adicionei o Demo que foi migrado para Lazarus por Roberto Brandão, Fiz um Refactoring de algumas funções que já existiam nos fontes do ACBr ou synapse: HTTPEncode -> synacode.EncodeURLElement; PosEx -> strutils.PosEx

Pode ser firewall... O protocolo "SVN" usa a porta 3690

Você pode tentar um novo checkout:

Veja esse tópico, (no antiga área do ACBr no ForumWeb) http://www.forumweb.com.br/foruns/topic/74093-pequenos-problemas-com-acbr/

Nossa intenção ao adotar a LGPL no ACBr era justamente permitir o uso dos componentes em projetos Comerciais... caso contrário nós mesmos como autores iniciais do projeto (DJSystem) não poderíamos comercializar os nossos programas que usam o ACBr Concordo que a LGPL se aplicaria melhor a projetos como o ACBrFramework... é realmente o mais correto seria usar uma licença parecida com a do Lazarus, LGPL modificada, pois os componentes ACBr são na maioria das vezes compilados estaticamente ao projeto final (assim como ocorre no Lazarus) Pretendo no futuro, rever a compatibilidade entre a LGPL que usamos com a LGPL modificada (pelo equipe do Lazarus)... para que isso fique mais claro. Mas fique tranquilo com isso, nossa intenção é permitir o uso dos componentes em Projetos Comerciais O ACBrMonitor por se tratar de um produto final, é G.P.L. Há várias formas de colaborar com o ACBr, contribuindo com fontes, com suporte, com divulgação, ou até mesmo financeiramente... Através do ACBrSAC

Realmente não existe tal retorno no ACBrECF... Podemos seguir dois caminhos: - Criar uma nova propriedade ACBrECF.DataEmissaoUltimaReducaoZ - Modificar a rotina GetDadosUltimaReducaoZ e inserir um novo campo na classe... Acredito que nem todos os ECFs tenham um comando específico para retornar essa informação (como o citado no tópico), e que alguns ECFs não retornarão essa informação nem mesmo na leitura dos dados da Ultima Reducao Z O que vocês acham ser o mais interessante ?

Sempre crie um novo tópico para um novo assunto... Por favor leia as regras do fórum

Realmente não é possível dar um aviso na hora do update do repositório antigo.... E o pior disso, é que os usuários acharam que estão com os fontes atualizados, pois o comando de Update continua funcionando... Apenas quando notarem que estão sem alguma nova funcionalidade que vários estão comentando é que começaram as perguntas... A própria comunidade do fórum poderia ajudar nesse momento... pois todo mundo que responde a mesma pergunta por 5, 10, 15 vezes... acaba se irritando...

Oi Doulgas, Estou trabalhando fora do pais até o dia 15...Se possível me envie um e-mail com o assunto... (meu email está no cabeçalho dos fontes do ACBr)

Você precisa informar a exata mensagem de erro... a melhor maneira de fazer isso é copiando trecho do LOG gerado pelo ACBrECF

Instruções para o Relocate Clique com o botão direito na pasta do ACBr Se você é um desenvolvedor do ACBr use a URL: svn+ssh://[email protected]/p/acbr/code/ Se você é um usuário do ACBr use a URL: svn://svn.code.sf.net/p/acbr/code/ (no meu caso (acima) fiz o download de todo o repositório e não apenas da pasta "trunk") Se tudo OK, vc terá a msg abaixo

Acho que o relocate já resolve... mas talvez seja mais simples renomear a pasta antiga e fazer o checkout em uma nova pasta

Usuários também devem fazer um NOVO CHECKOUT, pois o repositório atual está congelado (apenas para leitura)

Desenvolvedores devem fazer um NOVO checkout usando uma configuração semelhante a exibida na imagem abaixo