daniel.simoes

Poderia por favor anexar (zip) os fontes modificados ou ainda gerar um DIFF ?

Use a força... consulte os fontes... // Numero do Extrato ou Homologação // if (ide.tpAmb = taHomologacao) then NumExtrato := '000000' else NumExtrato := Trim( IntToStr( ide.nCFe ) );

Algumas impressoras apenas efetuam Truncamento... O ideal é você ler do ECF a maneira de calculo (Arredondamento/Truncamento), e replica-la no seu software

Não compreendi... Você fez correções nos fontes do ACBrSAT que gostaria de reverter para a comunidade ?

Acredito que semana que vem, teremos a "estreia" do Trunk2... (assim que o ACBrInstall ficar pronto)

Falei com a Bematech... eles estão me enviando uma MP4200 e um SAT... assim que chegar eu verifico os problemas encontrados...

Subi uma nova versão do que permite Ler Informações e o Status de Impressoras EscPos, (apenas para Porta Serial)

No "Trunk2" você pode regular o espaço entre linhas em uma propriedade do componente TACBrPosPrinter... Não estou mais trabalhando nos fontes do "trunk", ou seja, eu teria certa dificuldade de migrar as suas modificações do "trunk" para o "trunk2"...

Oi Joao, Muito obrigado pelos testes... Na Bematech, quais comandos não funcionaram ? (pode ser que esse modelo não suporte alguns dos comandos) Verifique se diminuindo o parâmetro "ConfigBarras.Largura", os códigos funcionam... A sintaxe de comando para Cod.Barras que estou usando, para EscPos (Epson/Bematech) é o método 2, onde sempre devemos informar o tamanho do Cod.Barras como parâmetro O Teste de Página de Código teve sucesso ?

Parece ser um Bug do Fortes Report... Ou uma característica dele... O que ocorre, é que o Fortes lê as métricas do Papel da Impressora do Windows... Você precisaria criar uma folha de papel customizada e deixá-la como default ... A meu ver, a solução não é boa, pois exigiria essa modificação em todas as instalações do windows... No FastReport existe uma propriedade "Roll" (ou algo parecido).. mas o Fortes não tem esse recurso... Meu conselho, é usar o modelo ACBrSATExtratoEscPOS

Veja a Linha: 75 - 14:09:38:674 - NumeroSessao: 767757 - Resposta:767757| Pegue o sexto parâmetro (conte os pipes "|") é uma longa sequencia de caracteres ASCII E use no site: https://www.base64decode.org/e cole o conteúdo (abaixo)... Observe no resultado gerado pela decodificação... que as observações do Fisco estão lá... Acho que o primeiro passo é entrar em contato com o fabricante.. talvez por algum Log deles, eles possam saber se essa informação está vindo do Fisco

João, por favor veja Download

Disponibilizei uma aplicação já compilada do PosPrinterTeste.exe Se possível, por favor testem todas as opções no seu modelo de Impressora

PosPrinterTeste.exe Visulizar Arquivo Programa de Teste e Exemplo do componente TACBrPosPrinter, que será disponibilizado no "trunk2"... Por favor execute com o seu modelo de Impressora NÃO fiscal, e reporte os resultados... -- ACBrPosPrinter -- [+] Criado novo componente: TACBrPosPrinter, que permite manipular Impressoras NAO fiscais, de bobina, usando a linguagem EscPos ou similares, por meio de TAGS no texto. Controla a formatação de caracteres Ex: Negrito, expandido, condensado, etc e a impressão de Cod.Barras e QRCode. Compatível com: ppEscPosEpson, ppEscBematech, ppEscDaruma Autor Daniel Simoes Enviado 06-05-2015 Categoria Demos / Testes / Utilitários  

Criei um novo método em ACBrUtil.pas, para ser usado nessas situações: function AnsiChr(b: Byte): AnsiChar; begin Result := AnsiChar(chr(); end;

Você precisa recompilar o seu package ACBrComum

No Trunk2, existe o componente TACBrPosPrinter... que atualmente é usado pelo ACBrSATExtratoESCPOS... Você poderia usar o TACBrPosPrinter para imprimir qualquer relatório, em impressoras EscPos... com controle de caracteres e suporte a códigos de barra... e ele seria compartilhado pelo ACBrSATExtratoESCPOS Muito em breve, teremos o ACBrInstall pronto para o Trunk2... e como isso iremos anunciá-lo ao fórum

Compreendido... o problema deve ocorrer principalmente nas versões mais novas do Delphi... HUmm... temos vários pontos desses... mas com "FindInFiles" é tranquilo para justar... Para usar o "Trunk2", é necessária uma instalação Limpa do ACBr... No Trunk2 há quebra de código... Ou seja, aproveitamos para remover propriedades não necessárias e efetuar outras correções que demandam alterações nos fontes... Na pasta principal, há um PDF que descreve algumas das principais diferenças

A alteração não deve ser feita no Extrato... Se a informação foi realmente retornada no XML, ela deve ser impressa... Veja o que diz a Especificação do SAT, pag: 91 Por favor anexe o Log gerado pelo componente ACBrSAT.. com ele podemos pegar o retorno do SAT ainda em Base64.. e abri-lo para gerar o XML na integra, como retornado pelo SAT... Isso comprovará se o SAT está ou não retornando essa informação... Se o SAT realmente estiver retornando esses campos preenchidos, eles devem ser impressos... (é a regra) Se a informação não faz sentido... precisaremos entrar em contato com os Fabricantes ou com o Fisco, para saber de onde e porque vem essa informação... PS: O problema não ocorre quando usando Emulador 2.8.8

Joao e demais.. Por favor analisem o seguinte commit no "trunk2" Estamos concluindo o Trunk2 e logo ele será o repositório oficial... Por favor analise os fontes: ACBrPosPrinter.pas, ACBrEscPosEpson.pas, ACBrEscDaruma.pas, ACBrEscBematech.pas (todos na pasta: \trunk2\Fontes\ACBrSerial) Ficará simples fazer impressão em Impressoras EscPOS.. sempre usando Tags.. veja um exemplo em "trunk2\Fontes\ACBrSAT\Extrato\EscPos\ACBrSATExtratoESCPOS.pas" procedure TACBrSATExtratoESCPOS.GerarRodape(CortaPapel: Boolean = True; Cancelamento: Boolean = False); var QRCode: AnsiString; begin FPosPrinter.Buffer.Add('</fn></linha_simples>'); if Cancelamento then FPosPrinter.Buffer.Add(ACBrStr('<n>DADOS DO CUPOM FISCAL ELETRÔNICO CANCELADO</n>')); FPosPrinter.Buffer.Add('</ce>SAT No. <n>'+IntToStr(CFe.ide.nserieSAT)+'</n>'); FPosPrinter.Buffer.Add(FormatDateTimeBr(CFe.ide.dEmi + CFe.ide.hEmi)); FPosPrinter.Buffer.Add(' '); FPosPrinter.Buffer.Add('<c>'+FormatarChaveAcesso(CFe.infCFe.ID)+'</fn>'); FPosPrinter.Buffer.Add(' '); FPosPrinter.Buffer.Add('<code128>'+copy(CFe.infCFe.ID,1,22)+'</code128>'); FPosPrinter.Buffer.Add('<code128>'+copy(CFe.infCFe.ID,23,22)+'</code128>'); FPosPrinter.Buffer.Add(' '); if ImprimeQRCode then begin QRCode := CalcularConteudoQRCode( CFe.infCFe.ID, CFe.ide.dEmi+CFe.ide.hEmi, CFe.Total.vCFe, Trim(CFe.Dest.CNPJCPF), CFe.ide.assinaturaQRCODE ); FPosPrinter.Buffer.Add('<qrcode>'+QRCode+'</qrcode>'); end; if CortaPapel then FPosPrinter.Buffer.Add('</corte_total>'); end; O componente foi criado, levando em consideração as implementações nos fontes: do ACBrNFeDANFeESCPOS.pas, ACBrSATExtratoESCPOS.pas e nos fontes do João

Parece ser um problema na Gaveta... Esse tipo de modelo, (RJ11) não requer tempo para carregamento de Capacitor... (no modelo Serial isso ocorreria) Tem como testar em outra gaveta ?

Provavelmente o Status é algum resíduo da última consulta... isso pode ser corrigido... O ACBrSAT chama a DLL dos fabricantes para a consulta... a lentidão é causada por elas... não há como modificar isso do lado do ACBr... Algumas DLLs possuem configuração de TimeOut...

No Delphi é o componente TWebBrowser No Lazarus é o componente: TSynMemo + TSynXMLSyn

Aparentemente você está usando o modelo errado... Use StdCall