Laercio Amici

Bom dia Elton. Desculpe a demora no retorno. Atualizei e testei, tudo OK. Obrigado. Laércio

@Juliomar Marchetti, boa tarde. Acho que pode ser uma incompatibilidade com 2 novas funções introduzidas na unit jsonsUtilsEx.pas. Nas linhas 16 e 197, eu havia incluído o mesmo define utilizado na função GetDecimalSeparator. No entanto, parece que as funções abaixo utilizam rotinas de acesso à RTTI ainda não disponíveis nas versões citadas: Function __ObjectToJson(aObject : TObject) : String; Procedure __jsonToObject(Const aJSONString : String; Var aObject : TObject); Eu alterei o define aqui para {$IFDEF DELPHIXE6_UP} e compilei novamente no XE6 e D7. Funcionou. Não tenho as versões XE e XE2 para testar, mas segue o pas alterado para verificação. jsonsutilsEx.pas

Sim, testei. No D7 funcionou perfeitamente, mas o @duardomribeiro usa o Delphi 2010, que não tenho aqui pra testar. O erro dele é o mesmo que eu estava tendo com o D7. Pesquisei no site da Embarcadero e havia encontrado referência ao record TFormatSettings a partir do Delphi 2009, e por isso incluí o {$IFDEF DELPHI2009_UP} na unit jsonsUtilsEx.pas. Fiz uma nova busca, e encontrei este link, dizendo que a var FormatSettings foi incluída no Delphi XE: http://delphiprogrammingdiary.blogspot.com/2019/04/formatsettings-or-tformatsettings-in.html Alterei a unit e troquei o ifdef anterior por {$IFDEF DELPHIXE_UP}, Compilei novamente com D7 e XE6, funcionou. Segue em anexo. Desculpe pelo equívoco, não tenho outras versões do Delphi instaladas. jsonsutilsEx.pas

Ok, testei no D7 e XE6. Funcionou sem problemas. Obrigado.

Bom dia Juliomar. Não uso o Lazarus, por isso não testei nele. Se alguém que usa o Lazarus puder testar, será bem-vindo. Obrigado.

Boa noite. Estou usando a jsons.pas, contida na pasta de Terceiros do ACBr, e me deparei com uma falha no tratamento de strings com caracteres com notação Unicode. Recebi um json com a string abaixo: "produto_descricao":"M\u00e9dia 8 Peda\u00e7os" Ao utilizar a classe TJson para ler este valor, o resultado obtido foi convertido para: JSon['produto_descricao'].AsString; // 'Mé#0dia 8 Pedaç#0os' Ou seja, após os caracteres acentuados é inserido um byte 0, e ao atribuir para uma variável a string é truncada. sStr := JSon['produto_descricao'].AsString; // 'Mé' Consultei https://github.com/rilyu/json4delphi e verifiquei que existe uma versão mais recente, que corrige esta falha. Baixei os fontes, fiz algumas adequações para o ACBr, compilei e testei com o Delphi 7 e Delphi XE6. Estou disponibilizando em anexo os .pas atualizados da pasta ACBR\Fontes\Terceiros\json4delphi\src para que sejam analisados e atualizados no repositório do ACBr. Obrigado. json4delphi-src.rar

Bom dia Juliomar. Sim, poderia ser um exemplo nativo. Mas a ideia seria fortalecer a comunidade ACBr, por isso pensei que um exemplo usando o componente seria melhor em termos de divulgação.

Bom dia Juliana. Sim, compilei no Delphi 7 e Delphi XE6.

Boa noite Gutemberg. Segue anexo com o componente ACBrFrenet. Gerei um rar somente com os arquivos alterados para a instalação do componente. Verifique o código do aplicativo de exemplo para ver como é realizado a chamada. Gostaria que os moderadores avaliassem a viabilidade de incorporar o componente ao ACBr. Tenho contato direto com a equipe do Frenet, e posso pleitear para eles incluírem o exemplo de chamada em ABCr Delphi no site da documentação (http://docs.frenetapi.apiary.io/). Tem várias linguagens de exemplo, mas nada em Delphi. Se precisarem de mais alguma informação ou ajuda, me avisem. ACBrFrenet.rar

Boa tarde. O componente está disponível para doação sim. Estou ajustando algumas propriedades novas do serviço do Frenet, e assim que concluir posto aqui novamente.

Boa noite Daniel. Já atualizei e testei novamente o componente. Funcionou corretamente. Obrigado.

Ok, obrigado Daniel.

No meu caso, utilizo 850 porque a impressora LX-300 em que testei está configurada com a página de código PC-850.

Boa noite a todos. Utilizamos o componente TACBrCHQ com o modelo chqImpressoraComum (classe TACBrCHQImpressoraComum) para imprimir cheques em uma Epson LX-300. Tivemos recentemente um cheque devolvido por motivo 31 (erro formal, normalmente relativo a erro de escrita) e foi quando notei que a acentuação não estava saindo correta na impressora (três estava sendo impresso como trÜs por exemplo). Para resolver este problema, criei uma nova propriedade TACBrCHQ.PaginaDeCodigo, que permite informar uma página de código para realizar a conversão de strings. Utilizei a TranslateString do próprio ACBr, e implementei a tradução apenas para a impressora comum, nos campos de extenso, mês e favorecido. Segue em anexo os fontes alterados e testados para serem incluídos no repositório, caso avaliem que esta implementação seja relevante. Obrigado, Laércio ACBrCHQ-PaginaDeCodigo.rar

Bom dia. Falei com o Regys a um tempo atras sobre um componente que desenvolvi para comunicação com o web service do Frenet e gostaria de doar para o ACBr. O Frenet é um gateway para cotação de fretes, onde são enviados os volumes a serem transportados e o sistema retorna as transportadoras disponíveis para o Cep destino e o valor do frete. Para utilizar o componente, é necessário criar uma conta no site e obter um token que será validado na chamada ao WS. Eles possuem contas gratuitas e pagas, dependendo da quantidade de transportadoras e numero de cotações mensais disponíveis. O site é http://www.frenet.com.br, e o painel para criar a conta é https://painel.frenet.com.br. Criei o componente seguindo a mesma estrutura do ACBrSedex, compilei com Delphi XE6 e Delphi 7. Só não compilei no Lazarus porque não tenho instalado. O componente já está em uso e estável a mais de 8 meses. Segue fontes e demo de uso em anexo. ACBR_Frenet.rar

Boa tarde. A classe está implementada no trunk 2, ACBrEscElgin.pas. A Elgin Vox imprime o QRCode, observando-se o seguinte: Precisa fazer a atualização do firmware. Tem link no tópico para download ou ver no site da Elgin; LarguraModulo não deve ser superior a 3 Acima de 250 caracteres no QRCode, a Elgin Vox até imprime, mas não fica legível. O QRCode do Sat-CFe é superior a esse limite, então vai imprimir "apenas para constar", porque não será possível a leitura. Esse limite é da própria impressora, segundo o suporte técnico da Elgin. Abraço, Laércio

Boa tarde pessoal. Antes de migrar para o trunk2, precisava manter compatibilidade com o trunk1, então fiz alguns ajustes nos fontes e consegui portar integralmente o PosPrinter para o trunk1. Estou mandando os fontes em anexo para que, caso alguém queira/necessite, possa utilizar o PosPrinter ainda no trunk1. Fiz os testes, inclusive da Elgin, com os fontes em anexo e funcionaram perfeitamente. Abraços, Laércio trunk1.rar

Olá Daniel. O QRCode com 426 caracteres não lê, mesmo no leitor genérico. Simplesmente não lê, ou quando lê (com muito custo) dá mensagem de código de barras inválido. O QRCode com 250 caracteres lê perfeitamente. Lembrando que só cheguei nesse número depois de entrar em contato com a Elgin, eles que me passaram esse limite. Inclusive me disseram que só chegaram a esse valor fazendo testes. Também perguntei sobre uma possível solução, argumentando que ia solicitar ao cliente para trocar a marcar da impressora, e a resposta foi negativa. Solicitei então uma resposta por escrito e me enviaram, então não tenho muita esperança numa solução por parte da Elgin. Sobre esse manual, já tinha visto também, veio num pacote que a Elgin me mandou, mas o comando é basicamente o mesmo que você já implementou. Vou alinhar meu código com o repositório e alterar o modelo para ppEscElgin. Abraço, Laércio

Daniel, boa noite. Testei seu código na Elgin VOX. Funciona exatamente como aquele que mandei no ACBrPosElginVOX.pas: Imprime, mas não lê. Também havia notado diferença entre o manual e o exemplo fornecido pela Elgin, mas nem me dei ao trabalho porque, em contato com eles, me mandaram um exemplo atualizado e a string de impressão era a mesma. O fato é que, como você citou, o manual diz realmente que o limite é 928 caracteres. O QRCode do Sat tem 426 caracteres. A Elgin imprime, mas o código não é legível, essa é a questão. Segundo o suporte da Elgin, é uma limitação da impressora, e o QRCode fica legível com, no máximo, 254 caracteres. Cortando o QRCode do Sat nos primeiros 250 caracteres, ficou legível. Acima disso não. Acho que você pode manter seu código no repositório, com um pequeno ajuste: Troque AnsiChr(LarguraModulo * 2) por AnsiChr(LarguraModulo) : Não pode multiplicar, quanto maior, pior. Observação: O limite máximo para imprimir o QRCode do SAT é LarguraModulo = 3. Maior do que isso, não imprime nada. Testei uma string de 250 caracteres e LarguraModulo = 4 e também imprimiu. Maior que isso, não imprime. Vai manter o ACBrEscElgin.pas no repositório? Se sim, vou alterar o meu pra deixar de acordo com o seu código. Abraço, Laércio

Daniel, boa noite. Estive trabalhando numa solução para Elgin, não sei se esse tópico aqui evoluiu. Por necessidade, implementei a classe TACBrEscElginVOX, herdada da Bematech. Nos meus testes, foi a impressão que melhor se adaptou, exceto pelos comandos do QRCode, que são diferentes. Mesmo sabendo que o QRCode não poderá ser usado no SAT, acho bom deixar implementado, pois respeitando o limite de 250 caracteres do QRCode Elgin, a impressão funciona bem, e fica legível (citei esses limites no tópico http://www.projetoacbr.com.br/forum/topic/23849-tamanho-do-qrcode-na-elgin-vox/). Estou anexando o ACBrPosElginVOX.pas, caso considere útil colocar no repositório. Fiz apenas algumas mudanças no ACBrPosPrinter.pas, segue abaixo.: type TACBrPosPrinterModelo = (ppTexto, ppEscPosEpson, ppEscBematech, ppEscDaruma, ppEscElginVOX); uses . . ACBrEscPosEpson, ACBrEscBematech, ACBrEscDaruma, ACBrEscElginVOX; procedure TACBrPosPrinter.SetModelo(AValue: TACBrPosPrinterModelo); . . . case AValue of ppEscPosEpson: FPosPrinterClass := TACBrEscPosEpson.Create(Self); ppEscBematech: FPosPrinterClass := TACBrEscBematech.Create(Self); ppEscDaruma: FPosPrinterClass := TACBrEscDaruma.Create(Self); ppEscElginVOX: FPosPrinterClass := TACBrEscElginVOX.Create(Self); ACBrEscElginVOX.pas

Pois é... mas o suporte da Elgin não me pareceu confiante numa solução, perguntei sobre alguma outra atualização (lembrando que a Elgin só imprimiu o QRCode após atualizar o Firmware) e me disseram não haver nada a fazer. Tanto é que pedi uma confirmação por escrito de que a impressora era incompatível - afinal vou ter que informar ao cliente para comprar outra impressora - e me responderam por e-mail confirmando a informação.

Jugger/Daniel, é isso mesmo, a Elgin VOX não vai imprimir corretamente o QRCode do SAT. Fiz o mesmo teste, e o maior tamanho que consegui foi usando Largura = 3, mas o QRCode impresso fica ilegível. Entrei em contato com o suporte da Elgin, e o problema é conhecido, e deve-se ao tamanho da string para impressão. A Elgin não suporta mais do que 254 caracteres - acima disso o QRCode torna-se ilegível. O suporte também me confirmou que isso não está presente em documentação alguma da Elgin, e só chegaram a esse valor fazendo testes.