EMBarbosa

E foi por isso que eu disse pra você comparar os valores... Mas qualquer coisa diferente nesse caso é muita coisa. Você pode usar o log gerado pelo ACBrESCPOS para analisar o que ele está enviando a impressora e comparar com o seu aplicativo. A propósito, no seu código: Em Java, char 0 não é final de string?

Esse erro na imagem é relacionado a conexão com o Source Forge. Não tem nenhuma relação com a versão do seu Delphi ou com o ACBr especificamente. Já esse erro acima é relacionado com o Fast Report. Você tem ele instalado no seu Delphi? A versão que você possui é qual?

Olá ALA. Eu ainda não entendi qual é o problema. Eu continuo sem entender o que precisa ser alterado no ACBrTEFD para corrigir. Você consegue me dar um exemplo? Diga, por favor, qual a sua expectativa de retorno do componente e como ela difere do que o componente está mostrando.

Acabei de enviar ao SVN. Revisão 17587. Você pode atualizar e testar. Queira reportar qualquer problema.

Você há de concordar comigo que alguma coisa está sendo transmitida de forma diferente. Sugiro você considerar possíveis diferenças nos dados transmitidos quando comparados em formato binário.

A quantidade de dados que o QR code suporta depende também da versão. Esse site abaixo tem uma tabela para saber quantos caracteres são possíveis em cada versão: https://www.qrcode.com/en/about/version.html Além disso, no manual da impressora você deve encontrar algumas situações em que o QR code não é impresso. Por exemplo, isso pode ter relação com o espaço disponível no papel para o código ocupar. Ou talvez com uma configuração não permitida para a impressora.

Dá uma olhada neste artigo com alguns exemplos: https://wiki.freepascal.org/paszlib#Zipping_a_whole_directory_tree_storing_only_a_relative_path

Não sei se isso está totalmente correto. Não encontrei no manual uma especificação de LarguraModulo. Por exemplo, no manual (versão 5.0) existe uma especificação de dimensão mínima de 25mm x 25mm (sendo 22mm de conteúdo e 3 mm para margem segura - "quiet zone"). Você encontrou alguma outra referência? Acho que essa alteração poderia causar problemas, vou pedir uma segunda opinião. Lembro de ter relatos aqui no fórum de que algumas impressoras só imprimem com uma LarguraModulo = 3. Sugiro testar com a minha unit acima.

Me parece que o campo cAut é o NSU do Host (campo 134 de 20 posições) e não o NSU do SiTef (campo 133 de 6 posições) e também não é o código autorização para as transações de crédito (campo 135 de 15 posições). Eu sugiro verificar com a Software Express/Skytef/Representante Sitef.

Me parece que está correto. Apenas não podemos esquecer de atualizar o dfm também.

Acabo de enviar ao SVN uma alteração para remover esses dados. É consenso entre os desenvolvedores que é preferível não mostrar uma informação do que a mostrar de forma incorreta ou incompleta. Ainda precisamos ajustar o layout para o novo formato que o Italo mencionou. Subi as alterações para o SVN na Revisão 17573. As alterações devem refletir no ACBrMonitor numa próxima versão.

Tópico Relacionado:

Qual o arquivo .fr3 que acontece esse problema? Poderia anexar arquivos xmls para reproduzir o problema?

Olá luizfr, O código que você enviou fez o inverso do que está atual, quer dizer, impede de informar um valor menor que 4: ifthen(FPosPrinter.ConfigQRCode.LarguraModulo < 4,4,FPosPrinter.ConfigQRCode.LarguraModulo) Além disso, notei que seu arquivo está desatualizado. Queira por favor: Atualizar o ACBr Substituir o arquivo pelo anexo testar Reportar qualquer problema ACBrNFeDANFeESCPOS.pas

Nesse caso você precisa converter do formato do SiTef para o do SAT, invertendo e adicionando a barra. Não tenho. Não tem no site do Integrador CE?

Não sei se você se atentou a descrição do campo, mas me parece que só existe código autorização quando é crédito mesmo. Veja Campo "135 - Contém o Código de Autorização para as transações de crédito (15 posições no máximo)". Já o campo 133, por sua própria descrição "Contém o NSU do SiTef (6 posições)" não é código de autorização. Me parece ser outro campo que não é atualmente tratado pelo ACBrTEFD. Existe algum outro motivo que você pense que a alteração seja necessária?

Então pode ser que a propriedade KeyPreview do Form esteja False. Mude para True. Esse artigo abaixo em inglês é muito explicativo sobre o assunto: https://www.thoughtco.com/understanding-keyboard-events-in-delphi-1058213

O Integrador CE não tem uma exigência de formato? Porque quando tem, você precisa usar o formato exigido independente do formato que você usa no aplicativo ou componente.

Mesmo que fosse, não há nenhuma diferença. Ele pode continuar compilando a aplicação dele tanto como Release como Debug que nada será afetado.

Me parece fazer sentido o que diz. Você poderia fazer as alterações e anexar o arquivo alterado para que possamos analisar?

Pode ser um bug no componente então. Ou no ClientDataSet ou no DBX que você usa por trás. Lembro de ter tido um problema como esse. Estava até no QC da Embarcadero...

Se no lugar do clear acontecer o mesmo problema com outros valores então possivelmente é problema na lógica mesmo. Talvez controle transacional.

Analisar isso está na minha lista de afazeres.

O que não está sendo tratado corretamente? Um campo? O tipo do cartão? O retorno? Existe um passo a passo para reproduzir o problema?

sua pergunta não faz sentido. Não se instala pacotes em debug ou release.