Daniel Simoes

O ACBrECF não depende de nenhuma DLL para operar... ele usa comunicação direta com a serial... O que me referia é conflitos de outro programa usando a DLL e bloqueando a porta seria... Isso ocorrerá por exemplo, se vc faz carga estática da DLL... Por favor teste primeiro com o ECFTeste... assim vc saberá se o problema não é nos seus fontes... Estude com atenção os fontes do demo.

Uso diariamente emulador de portas seriais em conjunto com vários emuladores de ECF, como por exemplo: Epson, Sweda, Bematech e FiscNET... e não tenho esse tipo de problema... por isso que desconfio que provavelmente os erros são algo no seu S.O.... ou ainda algum conflito do ACBrECF com alguma DLL de fabricantes de ECF

Em qual momento do Log acima, ocorreu o aviso de Pouco Papel ? Os erros de TimeOut podem indicar um problema no seu emulador de portas seriais... Não há problema desse tipo com o componente... centenas de desenvolvedores o utilizam com sucesso em diversos ECFs diferentes... Tente com um ECF real e verifique DICA: Primeiro estude e teste detalhadamente o exemplo do ACBrECF... o demo ECFTeste da pasta Exemplos

Nada de especial... criei um método próprio dentro do PDV... e devo sempre usa-lo ao invez de chamar os comandos diretos do ACBrECF... Exemplo, para leituraX temos: {-----------------------------------------------------------------------------} procedure TFrVenda.aLeituraXExecute(Sender: TObject); begin if errECFConfig in PDVErros then exit ; UIMemoProduto := '' ; { Grava o Documento no SQLite } Documento.Novo( StrToInt( ACBrECF1.NumCOO )+1, 'LX', Now, 'Leitura X' ); ACBrTEFD1.BloquearMouseTeclado( True ) ; try try ACBrECF1.LeituraX ; Documento.Finaliza( now ); dml.GravaAuditoria('PDV_ECF_LX','Leitura X') ; except { Se não imprimiu no ECF, Cancele tudo } Documento.Exclui ; raise ; end ; finally ACBrTEFD1.BloquearMouseTeclado( False ) ; end ; { Descarrega registros do SQLite para o FireBird... se houver conexão válida } dml.GravarArquivos ; end; [/code]

Apliquei uma possível correção que deve funcionar em todos os modelos... por favor verifique nos modelos que você possui... (já está no SVN)

E sempre haverá a possibilidade do ECF ser ligado em outro programa... (numa bancada de testes por exemplo)... e a aplicação ficará sem registrar esses documentos impressos... O governo nos "exige" algo quase impossível de cumprir... O que fiz foi centralizar todas as chamadas de métodos do ACBrECF em métodos internos/próprios, onde eu gravo adequadamente os dados...

Veja o Demo do novo componente ACBrEAD... Ele gera MD5, o EAD, a chave Privada/Publica., gera o XML para o eECFc... só não faz chover

Giuliano, Quais são os passos para a reprodução, usando o ECFTeste ? Notei que aparentemente já existe alguns IFs dentro do método TACBrECFFiscNET.FechaCupom para tratar essa situação...

Acredito que esse problema já foi corrigido... Hoje o ACBrECFBematech já é capaz de carregar alíquotas com zero (desde que não seja a última) Mas como foi dito aqui... Alíquota 0 é um erro... e em alguns casos pode levar o ECF a computar erroneamente os impostos

Pouco papel não é um erro... é um aviso... Falta de Papel sim, seria um erro

Sua sugestão está correta... este método está se comportando de forma diferente das demais classes.. Corrigi para: if DataHora = 0 then { Aparentemente a DataHora é obrigatória na Daruma } DataHora := TACBrECF(fpOwner).DataHora ;[/code] pois assim a solicitação de DataHora fica registrada no LOG

Apenas relembrando... É necessário re-instalar o Package ACBrSerial para que esses novos eventos apareçam no ObjectInspector

Pelo que notei na página: http://www.desenvolvedoresdaruma.com.br ... lphi_7.htm Todas as assinaturas de métodos mudaram... adeus compatibilidade...

A biblioteca synapse (usada pelo ACBrNFe) faz isso, usando vários plugins de bibliotecas de conexão segura (ex: OpenSSL) Veja um exemplo em: http://www.ararat.cz/synapse/doku.php/p ... 3samplessl

Oi Dirceu, Muito bacana essa sua iniciativa... Atualmente o ACBr é compatível apenas com ObjectPascal (Delphi / Lazarus)... Ha algum tempo atrás criou-se o JACBr... http://sourceforge.net/projects/jacbr/ O que seria o mais indicado para esses fontes... mas não sei como está o andamento do projeto... Também houvi dizer que o pessoal da T2TI estava traduzindo o ACBr para Java... (você poderia somar forças) http://www.t2ti.com/ Há ainda a possibilidade de criarmos uma área Java no ACBr atual... mas seria necessário um outro administrador (o que exige bastante dedicação), pois eu não conheço nada de Java

Carlos, Obrigado pela oferta... mas um componente deste não é o escopo do Projeto ACBr (Automação Comercial)... Outro problema para integra-lo com o ACBr é que um componente desses dificilmente será independente de IDE ou S.O. (o que quebra uma das premissas do ACBr)

Qual é a exata msg de erro ? A DLL e o ACBrECF não podem abrir a mesma porta ao mesmo tempo... vc precisa desativar o ACBrECF primeiro... veja os fontes de ACBrECFBematech.pas no método ArquivoMFD_DLL

Vc tm pode recorrer ao LOG de alterações de qualquer arquivo versionado, e comparar a versão atual com uma anterior... Use o botão direito do mouse sobre o arquivo... Tortoise SVN -> Show Log

Não para a Nota Fiscal Paulista... o ACBrRFD gera este arquivo, mas foi projetado para capturar as informações de ECFs matriciais apenas, gerando o arquivo concomitante com a impressão no ECF

Não... de forma alguma... O formato .INI é apenas uma maneira simples de você conseguir ler todos os dados... Exemplo: Salve o conteúdo dele em um "Arquivo.ini" e use o TIniFile do Delphi para manipula-lo.... ou ainda use um TMemIniFile

provavelmente precisaremos rever isso... Está na minha lista de "coisas a fazer" uma modificação para a Daruma feita pelo José Nilton (JNP)... que contempla novos métodos da DLL... quando for incorporar nos fontes, vou tentar descobrir se os mesmos existem tb nessa DarumaFrameWork

Em time que está ganhando não se mexe Vai com o mesmo conjunto que você passou... é apenas mais 1 dia... Na próxima você já se prepara para ir com o NoteBook

Na minha opinião isso será um "tiro no pé" O programador pensa: "Humm.. vou precisar mudar meus fontes... nesse caso, porque não mudar para outra DLL, de outro equipamento ? (ou até mesmo ACBrECF)" Acho que eles aprenderam com o fisco... a decisão vem sem uma consulta pública... e de forma arbitrária... Qual é a necessidade ou vantagem de quebrar a compatibilidade ?? Nenhuma. poderiam pelo menos manter a assinatura dos métodos...

é possível capturar direto da MFD... mas para isso é necessário um programa disponibilizado pelo fabricante do equipamento... quanto a salvar em arquivo, ou BD, sem problemas... o método DadosReducaoZ retorna o conteúdo de um arquivo TXT no formato .INI A Nota Fiscal paulista pode ser gerada do seu banco de dados, desde que vc possua todas as informações necessárias para compor o arquivo, de todos os documentos impressos pelo ECF... alias isso é o recomendado, pois PAF-ECF, SPED, Sintegra também podem se beneficiar dessa mesma base... e a obrigatoriedade de gerar os arquivos permanece, mesmo que o ECF seja "queimado", roubado, extraviado, etc... (ou seja, mesmo que você não tenha como acessar a MFD do mesmo)

Oi Giuliano, Desculpe-me não poder ter lhe ajudado... e parabéns pela sua persistência... Muito Obrigado pela sua colaboração... vou analisa-la hoje a noite, e se tudo OK já mando pro SVN...