Daniel Simoes

O Captcha mudou, e utiliza PNG... O Demo já está atualizado... Verifique se sua IDE suporta PNG, caso contrário você precisará adicionar um Package de terceiros

Não recebemos da Daruma, um ECF desses para testes... e Infelizmente não há Emulador do mesmo... Por favor anexe o Log gerado... pode ser que dê uma pista da diferença do retorno desse ECF em relação ao protocolo padrão...

No seu arquivo de Log, não existe nenhum ERRO...

Provavelmente SIM, vamos verificar... mas hoje em dia há o SAC do ACBr http://www.projetoacbr.com.br/forum/index.php?/page/SAC/sobre_o_sac.html

Assim como os demais componentes do ACBr... a maneira de estudá-lo, é abrir a aplicação Demo (SATTeste) e ler atentamente os fontes...

O André é "danado" mesmo... mesmo sem ter participado desse tópico ele resolveu o problema... Leia com mais atenção... meu nome é Daniel

Não tenho certeza... eu fiz o Extrato para o SAT em ESCPOS e FortesReport... as versões do DANFE da NFCe, derivam desses códigos.. Um problema conhecido, que temos com o Extrato SAT em Fortes Report, é o fato de que o Fortes não existe o conceito de Relatório em bobina... e isso exige que o usuário crie no windows um formulário com a altura customizada...

A única coisa que conheço, é o endereço do projeto: https://github.com/fortesinformatica/fortesreport-ce Como eu uso Lazarus/FPC.. eu uso o Fortes4Lazarus http://fortes4lazarus.sourceforge.net/

Comece lendo a documentação do SAT http://www.fazenda.sp.gov.br/sat/downloads/vigentes.asp Procure por: "Especificação de Requisitos do SAT"... não precisa ler as sessões que dizem respeito a implementação técnica do equipamento, mas vc precisa conhecer o XML, e os princípios de funcionamento do SAT, além dos comandos disponíveis

Apliquei uma possível correção no SVN

Aparentemente esse SAT inclui quebras de linha no Retorno do Encode64 do XML... e isso está atrapalhando a interpretação do componente... Vou aplicar um workaround

Essa versão é para a extinta CLX (veja o prefixo "Q" nas Units)

Não sei ao certo... mas logo alguém aqui complementa a minha resposta... A AFRAC tem um mapa bem interessante... http://www.afrac.org.br/mapas/ (clique na aba Tendências)

Vamos esperar o André responder...

Use o DANFE em ESCPOS... pois ele usa a linguagem de caracter, nativa das Impressoras de bobina (ESCPOS)... O que torna a impressão muito mais rápida de leve... além do uso de fontes nativas, o que torna o conteúdo mais legível...

Não há uma regra geral... Isso depende de cada UF

Acho que compreendi o que está gerando o problema... enviei os seguintes ajustes para o SVN

Qual Unit e linha ???

Antonio, Se você quer resolver apenas a impressão do DANFE para NFCe.... Use uma versão de DANFE com ESCPOS, que não necessita da instalação de nenhum gerador de relatório

Qual é a Tag que está sendo convertida ? Parece ser um problema de conversão do D7, não é difícil tratar, bastaria usar um try/except na conversão... Ex: try ConteudoProcessado := IntToStr(valor) except ConteudoProcessado := '0' end; Mas muito provavelmente essa Tag não deveria ser vazia... O que você quer dizer com "icms tem sempre que enviar"... Poderia ser mais específico ?

Em uma reunião recente com a equipe de programadores, decidimos que SIM, alguns dos argumentos, foi o fato de que a própria Embarcadero abandonou o Rave... A nova versão do ACBrNFeMonitor, será feita em Lazarus (não dependerá do uso do Rave) Mas isso não significa que o Package do Rave não possa ser mantido pela comunidade... é apenas o fato de que a equipe do ACBr deixará de revisá-lo... Como eu uso apenas Lazarus... não opinei... Há um tópico com uma enquete sobre isso, fixo no fórum:

O erro ocorre na linha abaixo ? pcnGerador.pas -> ConteudoProcessado := IntToStr(valor); Se SIM, qual é o conteúdo de "Valor" no momento do erro ? Qual campo está sendo convertido ? (veja no Call Stack)

O suporte a RAV será descontinuado pela equipe do ACBr... O motivo é a dificuldade em manter e dar suporte aos diversos geradores de relatório existentes... Com isso, não temos planos em fazer um DANFE para NFCe com o Rave Sugiro usar o Fortes Report, pois o mesmo é OpenSource e pode ser usado em todas as edições do Delphi e Lazarus

Eu não vejo como essa sugestão, ou a anterior, poderia corrigir um Access Violation... Não temos relatos de outros usuários tendo A.V. nesse código... A.V. ocorre quando tentamos acessar um objeto que nunca existiu ou que já foi destruído... Qual é a sua analise para o problema estar ocorrendo ? E como a sua correção pode solucioná-lo ?

Ademar, Creio que a modificação não possa ser aplicada, pois pode quebrar aplicações existentes... e pelo que analisei, o nome do INI está sendo atribuído corretamente {$IFDEF CPU64} IniFile := ExtractFilePath( PathDLL )+'BemaFi64.INI' ; {$ELSE} IniFile := ExtractFilePath( PathDLL )+'BemaFi32.INI' ; {$ENDIF} O INI deve ficar na mesma pasta da DLL, e as linhas acima, garantem isso... Se mudarmos para o proposto: Ini := TIniFile.Create( aPath+IniFile ); O INI será criado no diretório de destino, informado pelo programador, no momento da geração do arquivo...