Daniel Simoes

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

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

E qual é a msg de erro afinal ?

Aparentemente você seguiu os passos corretos... Não sei o que possa ser... Verifique se não existe a DLL da Bematech em outras pastas...

Qual é exatamente a Unit que ocorre esse erro ? TDate não existe no D7... teria que ser substituído por TDateTime

O valor 3 provavelmente equivaleria a RTSimplesNacional, a tradução de Integer para Tipos enumerados não causa estouro no caso de um valor maior... mas ele faz um "loop" do contador...