EMBarbosa

O ACBrTEFD não tem condições de gerar esse tipo de arquivo. Apenas a administradora pode lhe instruir como gerar.

Na verdade, a unit TACBrBALClass se encarrega de fazer isso. Ela mesma já tem um método SolicitarPeso. Não vejo nem o porque de SolicitarPeso estar sendo sobrescrita na unit ACBrBALToledo2090.

Nesse caso, me parece problema de firmware ou hardware da impressora. Mas só pra garantir: No log do componente há algo estranho? Ahhh!! Vale lembrar que uma SI 300S foi homologada pelo ACBr:

Muito obrigado por ter notado Daniel. Fiz as alterações e espero não ter quebrado nada. Enviei no SVN na revisão 15867. Sim. É melhor quando adicionada. Por isso adicionei no commit acima também.

Se fechar a aplicação e abrir novamente funciona? Ou é preciso desligar a impressora?

Ahh sim. Tinha esquecido desse tópico. Existe esse outro tópico abaixo que foi dividido desse, que tem uma implementação usando DLL. Mas como a comunicação é por meio de DLL, não devemos incorporar o código.

Esse erro acontece por causa de problemas na instalação do Fast Report. Ao tentar compilar o pacote "ACBr_NFeDanfeFR.dpk", foi detectado que o pacote frxe25 (que é do Fast Report) precisa ser recompilado. Provavelmente precisa ser recompilado porque a interface de alguma de suas dependências foram alteradas. Claro que não foi alterada pelos componentes do ACBr, porque ele não faz isso na instalação. Mas acontece que esse pacote frxe25 é marcado como "Never-Build", quer dizer nunca reconstrua. Isso gera o erro. Se você tiver o código fonte do Fast Report, pode tentar abrir esse pacote e recompilar ele manualmente.

Tentou configurar a impressora? Veja:

Esse tópico foi dividido do seguinte tópico: https://www.projetoacbr.com.br/forum/topic/12259-ler-peso-balança-rodoviária-toledo/?page=2

Essas sugestões foram enviadas ao SVN na revisão 15861. Queira por favor avaliar e reportar qualquer problema. Essa implementação parece realmente incompleta. Está funcionando?

Enviado ao SVN na revisão 15860. Por favor, queira testar e reportar qualquer problema. Obrigado.

Marque a opção para fazer a limpeza do ACBr. Esse caminho está estranho. Você está instalando pro C++ Builder?

Dá uma olhada no DJPDV. https://www.djpdv.com.br/

As sugestões foram enviadas com algumas alterações ao SVN na revisão 15858. Queira, por favor, testar e dar um retorno.

Estranho, isso não é normal. Não consegui reproduzir. Mas que bom que conseguiu um jeito pra funcionar. ?

Esse exemplo acima mesmo. Ele usa parcialmente um TStringStream. Mas se você for utilizar diretamente Streams, você pode utilizar os métodos ZCompressStream(); ZDecompressStream();

Segue: program Project1; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.Classes, System.ZLib; var Input, output, descomp: string; bb: TStringStream; begin try { TODO -oUser -cConsole Main : Insert code here } Input := 'String a ser compactada'; bb := TStringStream.Create(ZCompressStr(Input)); Output := bb.DataString; Writeln(output); readln; descomp := ZDecompressStr(bb.Bytes); Writeln(descomp); readln; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end. Como eu disse acima, seria melhor você esquecer esse negócio de compactar string e começar a trabalhar com streams. Ao salvar uma string compactada no BD você pode ter problemas ao fazer o processo inverso.

A ZLib está disponível no Delphi. O programa console abaixo dá uma ideia, mas seria melhor você trabalhar com streams ao invés de strings. program Project1; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.Classes, System.ZLib; var Input, output: string; bb: TStringStream; begin try { TODO -oUser -cConsole Main : Insert code here } Input := 'String a ser compactada'; bb := TStringStream.Create(ZCompressStr(Input)); Output := bb.DataString; Writeln(output); readln; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end.

Olá pessoal. Temos novidades na área das impressões dos DF-e. Com o objetivo de facilitar o trabalho e reduzir a duplicação de código, estamos promovendo um refactoring nas classes de impressões de DF-e. Essas alterações ainda não foram enviadas ao SVN, mas queremos avisar com antecedência para que todos possam se preparar. Fizemos um vídeo para explicar os objetivos e as principais alterações. Você pode acessar aqui: Mas... se você não é muito fã de vídeos, vou resumir os principais pontos nesse tópico. Os objetivos desse refactoring são: Diminuir código duplicado; Padronizar os componentes de impressão; Isso vai simplificar o trabalho com componentes diferentes; Minimiza a necessidade de aprender vários detalhes diferentes; Melhor organização de código; Mais fácil pra você ler, entender e debugar o código; Lançar base para melhorias futuras; Podemos resumir a principal diferença como: Agora há classes para padronizar o comportamento mesmo em componentes de impressão diferentes. Na nova estrutura os componentes de impressão herdam da classe base TACBrDFeReport (unit ACBrDFeReport.pas) que se encontra no pacote ACBrDFeComum. Esta classe visa englobar todas as propriedades e/ou métodos que são usados por todas as impressões DFe. Por exemplo: PathPDF, CasasDecimais, etc.. Se assemelha a esse organograma: Veja algumas propriedades que foram alteradas, removidas ou mudaram de nome: Essas são as modificações principais. Podem haver outras, mas acreditamos que são menores e darão menos dor de cabeça. A previsão é enviar ao SVN antes do Dia do ACBr. Assim que enviarmos ao SVN vou postar uma nova mensagem aqui.

Que procedimentos? Qual é o erro? Que tópicos?

Pra saber se realmente foi alguma alteração no código, eu precisaria saber qual versão você estava antes de atualizar. No arquivo do DANFCe usado para gerar o report.

Desde que data você não atualizava?

Enviado ao repositório na revisão 15843. Favor avaliar e reportar qualquer problema. Nós que agradecemos.