Daniel Simoes

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

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)

Vamos esperar o André responder...

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

Qual Unit e linha ???

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 ?

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)

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...

Consegui recriar o XML retornado... mas não consegui reproduzir o erro... Qual é a sua IDE ? Sabe exatamente em qual linha dos fontes o problema ocorre ?

Nunca testei com esse equipamento... mas em todo caso, deveria funcionar, pois a especificação é padrão... Com o LOG, posso tentar recriar o XML retornado, e verificar o que houve... Por favor aguarde a próxima interação...

Defina o nome do arquivo em: "ACBrECF.ArqLOG"

Verifique se ele realmente passa por essa rotina... A analise do Log gerado pelo ACBrECF pode elucidar essa questão...

Talvez o ECF subtotalize automaticamente quando você fecha com Dinheiro... A pergunta é: Você está ou não enviando o comando de SubTotalização ? Ele é necessário...

No "trunk2", eu já fiz um estudo de vários lugares, onde o "DecimalSeparator" era utilizado... e na maioria dos casos, a modificação foi passar usar algum método de conversão da ACBrUtil Na ACBrUtil.pas, do Trunk2, está com os IFDEFs...para evitar os "warnings"... Pois mesmo usando a ACBrConsts.pas, os warnings continuam aparecendo no Lazarus No Trunk2 crie uma diretiva nova no ACBr.inc

Se deseja sugerir modificações, favor anexar os fontes modificados ou um patch

Aparentemente está faltando enviar o comando de SubTotal, antes de iniciar os pagamentos...

Sim... adicionar o "uses ACBrConsts" a essa Unit seria uma maneira de corrigir o problema... mas o que estou demonstrando com a Imagem acima, é que isso não foi feito... Fique a vontade para promover a modificação...

Acho que estávamos falando de Units diferentes... Eu inseri um IFDEF na ACBrSATExtratoClass.pas... Notei pelo Log que não houve modificações anteriores...

Não compreendi a necessidade da modificação... a Linha parece correta... afinal o nome do método é "FinalizarEtiqueta", após a execução desse método o usuário realmente precisa Iniciar uma nova etiqueta Se tiverem algum bug para reportar, favor descrever um PASSO a PASSO usando a aplicação Demo do ACBrETQ

Poderia por favor ser mais específico ? De qual Unit ? De qual método ? ou ainda qual numero da Linha ?

Humm.. esse pode ser o problema... essa Unit não faz "uses" do ACBrConsts... acho que é só adicionar o mesmo...