Ir para conteúdo
  • Cadastre-se

Leandro Araújo

Membros
  • Total de ítens

    145
  • Registro em

  • Última visita

Últimos Visitantes

1.748 visualizações

Leandro Araújo's Achievements

Collaborator

Collaborator (7/14)

  • Reacting Well Rare
  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done

Recent Badges

18

Reputação

3

Community Answers

  1. Boa tarde. Pois é, eu realizei vários testes, e além de não imprimir o QRCode (imprime o texto no lugar do QRCode) percebi que as formatações não são respeitadas na hora da impressão. Vou fechar o tópico então. Obrigado!
  2. Bom dia. Estou realizando testes com o ACBrPOSPrinter com a impressora Diebold IM453HU-002, mas a mesma não imprime QRCode. Vi que no tópico abaixo outra pessoa conseguiu configurando como "ppEscBematech". Já tentei com ppEscBematch e outros, também testando as code page 437 e 850 (no manual é informado suporte para essas páginas de código), mas sem sucesso. Uma coisa que observei é que no manual diz que o suporte para impressão de QRCode é pelo set de comandos padrão (ao que dá a entender, pelo menos no meu entendimento, não sendo esc/pos). Poderiam dizer se essa impressora foi homologada para o ACBr? Estou achando que ela não tem suporte para impressão de QRCode por comandos ESC/POS. Se alguém que já trabalhou com ela puder me informar. Obrigado.
  3. * Conclusão: Não foi possível fazer a impressora funcionar. * Motivos: A marca/modelo da impressora parece não ter suporte para comandos "ESC/POS", que são necessários para impressão universal em impressoras térmicas. * Tentativas: Foi pesquisado nos manuais, especificações técnicas e nas configurações da impressora e nada referente a linguagem "ESC/POS" foi encontrado. Também foi utilizado programa exemplo do ACBr, com componente de impressão do ACBr (ACBrPosPrinter), para testar a impressão, mas sem sucesso. * Observações: Ela ainda pode servir para a impressão de etiquetas, mas ainda assim também parece não ter suporte para linguagens "PPLA, PPLB ou ZPL2", que são necessárias para impressão universal em impressoras de etiquetas. Talvez por ser de fabricação de uma marca chinesa específica, essa impressora parece trabalhar bem somente com um programa proprietário (NiceLabel Designer/NiceLabel Print) (para impressão de etiquetas). Obrigado!
  4. Já tentei todos os codepage. Sobre ela ter comandos ESC POS, estou pesquisando as especificações, mas encontrei pouca coisa a respeito, nem o manual.
  5. Bom dia. Gostaria de saber se alguém já trabalhou com a impressora GPrinter modelo GP-3120TU usando o ACBrPOSPrinter? Estou realizando testes em uma, com o exemplo fornecido pelo ACBr mas não sai nenhuma impressão. A página de testes pelo Windows funciona, e do mesmo modo se eu tentar imprimir um .txt pelo bloco de notas. No exemplo do ACBrPOSPrinter ele consegue listar a porta USB "USB:Gprinter GP-3120TU" e também a porta RAW "RAW:Gprinter GP-3120TU" e ativa sem indicar nenhum erro, mas ao tentar enviar texto para impressão nada acontece. Tentei também por compartilhamento da impressora, e informando a porta \\127.0.0.1\GP-3120TU no componente, também ativa sem erro, mas ao enviar texto para impressão nada é impresso. Tentei alterar as propriedades da impressora no Windows para usar porta COM, mas quando faço isso, ao tentar ativar a impressora ocorre o erro "First chance exception at $76B87452. Exception class ESynaSerError with message 'Communication error 1: Função incorreta'.". Então mantive a comunicação pela porta USB mesmo, acredito que seja o mais recomendado. Já olhei o log e lá não é indicado nenhum erro. Obs.: A Code Page da impressora é 437 e isso também está configurado de acordo no ACBrPOSPrinter como pc437. Obs.2: Já resetei a impressora para os padrões de fábrica também. Marca: GPrinter Modelo: GP-3120TU Versão: V1.1 (G 2018-06-07) Interface: USB Label Value: 525 506 994 1-14 752 65 Size 80mm, 101mm Chinese GB18030: TSS24.BF2 Se alguém souber se tem alguma configuração específica que tenha que ser realizada nas opções dessa impressora para funcionar com o ACBrPosPrinter eu agradeço.
  6. Bom dia.. Observei que o problema possivelmente poderia ser resolvido também alterando o valor das propriedades PosIni e PosFim do componente ACBrBAL e trabalhar com isso dentro da unit ACBrBALSaturno (que não deixa de ser inválido para uma implementação futura), mas ainda assim ficariam margens para erros inesperados, sem garantias de que o retorno possa vir no tamanho esperado/especificado, porém, conforme as alterações acima, agora a resposta de peso está sendo sanitizada (limpada) por completo, então no meu ver acredito que as melhorias possam ajudar de alguma forma. Caso eu possa marcar o post como resolvido ou tenha que aguardar, me avisem por favor. Obrigado!
  7. Boa tarde... Consegui identificar o que estava acontecendo. O retorno recebido da balança continha CarriageReturn (#13) que não eram tratados quando entrava na primeira condição do if wAchouE or wAchouO then da função InterpretarRepostaPeso da unit ACBrBALSaturno, já que a remoção de caracteres especiais não estava tratando os caracteres #13 e #10, e no else estavam sendo tratados, fazendo que com dependendo do tamanho do pacote a conversão da resposta pela função StrToFloat sempre caísse no bloco Except. Trecho anterior (Condição if da função InterpretarRepostaPeso: if wAchouE then wPosEO := Pos('E', UpperCase(aResposta)) else wPosEO := Pos('O', UpperCase(aResposta)); wResposta := Copy(aResposta, 0, wPosEO - 1); { Removendo caracteres especiais, caso encontre algum } wResposta := StringReplace(wResposta, '°', '0', [rfReplaceAll]); wResposta := StringReplace(wResposta, '±', '1', [rfReplaceAll]); wResposta := StringReplace(wResposta, '²', '2', [rfReplaceAll]); wResposta := StringReplace(wResposta, '³', '3', [rfReplaceAll]); wResposta := StringReplace(wResposta, '´', '4', [rfReplaceAll]); wResposta := StringReplace(wResposta, 'µ', '5', [rfReplaceAll]); wResposta := StringReplace(wResposta, '¶', '6', [rfReplaceAll]); wResposta := StringReplace(wResposta, '·', '7', [rfReplaceAll]); wResposta := StringReplace(wResposta, '¸', '8', [rfReplaceAll]); wResposta := StringReplace(wResposta, '¹', '9', [rfReplaceAll]); // Sem tratamento para #13 e #10 end Acabei unificando a remoção dos caracteres especiais em uma function interna SanitizarRespostaPeso(const aResposta: AnsiString) : AnsiString; e deixando nela também o tratamento para #13 e #10 (igual estava condição else) independente se na reposta de peso forem encontrados os indicadores de Estado do Peso (Caracteres "E" ou "O"). Também passei para remover os valores inválidos antes de tentar localizar os indicadores de Estado do Peso, pois imagino que de qualquer forma os caracteres especiais devem ser removidos nos dois casos (de ter localizado indicador de Estado do Peso ou não), caso isso estiver errado posso corrigir. Modifiquei também para ler o valor do parâmetro aResposta somente no início, passando para a variável wResposta, para a partir disso o método somente trabalhar com o valor de wResposta já sanitizado. Segue abaixo o trecho modificado de InterpretarRepostaPeso na unit ACBrBALSaturno: function TACBrBALSaturno.InterpretarRepostaPeso(const aResposta: AnsiString): Double; var wAchouE, wAchouO: Boolean; wPosEO: Integer; wResposta: AnsiString; function SanitizarRespostaPeso(const aResposta: AnsiString) : AnsiString; begin Result := Trim(aResposta); if Result = EmptyStr then Exit; Result := StringReplace(Result, '°', '0', [rfReplaceAll]); Result := StringReplace(Result, '±', '1', [rfReplaceAll]); Result := StringReplace(Result, '²', '2', [rfReplaceAll]); Result := StringReplace(Result, '³', '3', [rfReplaceAll]); Result := StringReplace(Result, '´', '4', [rfReplaceAll]); Result := StringReplace(Result, 'µ', '5', [rfReplaceAll]); Result := StringReplace(Result, '¶', '6', [rfReplaceAll]); Result := StringReplace(Result, '·', '7', [rfReplaceAll]); Result := StringReplace(Result, '¸', '8', [rfReplaceAll]); Result := StringReplace(Result, '¹', '9', [rfReplaceAll]); Result := StringReplace(Result, #13, '', [rfReplaceAll]); Result := StringReplace(Result, #10, '', [rfReplaceAll]); Result := StringReplace(Result, '[CR]', '', [rfReplaceAll]); Result := StringReplace(Result, '[LF]', '', [rfReplaceAll]); end; begin Result := 0; wAchouE := False; wAchouO := False; wPosEO := -1; wResposta := EmptyStr; { Removendo caracteres especiais, caso encontre algum } wResposta := SanitizarRespostaPeso(aResposta); if (Trim(wResposta) = EmptyStr) then Exit; wAchouE := (Pos('E', UpperCase(wResposta)) > 0); wAchouO := (Pos('O', UpperCase(wResposta)) > 0); // Se encontrar a letra 'E' (Estável) ou 'O' (Oscilante), captura o peso da // posição 1 a 7 da string if wAchouE or wAchouO then begin if wAchouE then wPosEO := Pos('E', UpperCase(wResposta)) else wPosEO := Pos('O', UpperCase(wResposta)); wResposta := Copy(wResposta, 0, wPosEO - 1); end else begin wResposta := Copy(wResposta, 1, 9); end; if (Length(wResposta) > 0) then begin try Result := StrToFloat(wResposta); except case PadLeft(Trim(wResposta),1)[1] of 'I': Result := -1; { Instavel } 'N': Result := -2; { Peso Negativo } 'S': Result := -10; { Sobrecarga de Peso } else Result := 0; end; end; end else Result := 0; end; Segue em anexo o código-fonte completo alterado, caso puder ser analisado por algum committer do projeto ACBr e ser ou não adicionado no trunk. Ainda com relação a gravação do log de pesagem, desculpem o equívoco, acredito que o componente está gravando correto, favor desconsiderar essa questão. Qualquer dúvida ou erro estou a disposição. Obrigado. ACBrBALSaturno.pas
  8. Bom dia... Consegui a informação referente ao Indicador de Pesagem (Marca: WEIGHTECH Modelo: WT27). Na página oficial (https://www.weightech.com.br/indicador-de-pesagem-wt27) não consegui baixar o manual técnico, tive que encontrar em outra fonte. Até onde entendi, era o que eu suspeitava, é possível personalizar um protocolo para envio dos dados. No caso a mensagem de leitura respeita o protocolo da Saturno, mas parece que incluíram os textos [CR] e [LF] em forma literal ou então o ACBrBALClass está gravando dessa forma no log. Estou analisando melhor os manuais obtidos, para ver se a modificação na interpretação da resposta de pesagem pode ser mantida na ACBrBALSaturno mesmo ou se é o necessário a criação de uma nova unit (caso os administradores aceitem a alteração). Nos manuais que encontrei a mensagem de resposta parece ser no formato: Seguem as fontes de onde consegui os manuais: WT27: https://www.yumpu.com/pt/document/read/49558520/indicador-digital-wt27-manualpdf-weightech WT27R http://primaxbalancas.com.br/wp-content/uploads/Manual-técnico-WT-27-R.pdf https://www.balancasrr.com.br/indicadoresweightech https://drive.google.com/file/d/1rtKlOvnztysnJHhVMcvyqTVrlY8_-U1o/view Obrigado.
  9. Boa tarde. Estou realizando a integração do nosso sistema com uma balança da marca Saturno. O padrão de resposta é composto juntamente com os indicadores de peso (Estabilidade do Peso e Estado da Balança) <CR>, PPPPPP, “E”/“O”, “L”/“B”, “_”, “ ”, <LF> (Conforme manual de integração), por exemplo: 023060EL_. Onde: <CR> = Carriage Return (#13), PPPPPP = Peso na Balança, E/O = Estado do Peso, L/B = Estado da Balança, <LF> = Line Feed. Testando o retorno por um outro software (Hercules SETUP utility) o retorno vem da seguinte forma no próprio Hercules utility: 006320OL_. Copiando esse valor e informando no "Exemplo de Emulador de Balanças do ACBr" e enviando, o retorno é interpretado corretamente pela classe TACBrBALSaturno da Unit ACBrBALSaturno no nosso sistema e peso é exibido de forma correta. Porém, ao realizar a leitura diretamente pela porta COM, o peso recebido fica zerado sempre, e observei que conforme o log de pesagem, ao que parece os textos [CR] e [LF] estão sendo recebidos de forma literal diretamente na resposta. Realizei o tratamento no método InterpretarRepostaPeso, também removendo esses textos (CR e LF) e ao que parece, classe passou a interpretar corretamente nesse caso. Obs.: Sei que CR = Carriage Return e LF = Line Feed, ambos sendo representados por #13 e #10 consecutivamente. Segue abaixo onde foi modificado (duas últimas linhas). if wAchouE or wAchouO then begin if wAchouE then wPosEO := Pos('E', UpperCase(aResposta)) else wPosEO := Pos('O', UpperCase(aResposta)); wResposta := Copy(aResposta, 0, wPosEO - 1); { Removendo caracteres especiais, caso encontre algum } wResposta := StringReplace(wResposta, '°', '0', [rfReplaceAll]); wResposta := StringReplace(wResposta, '±', '1', [rfReplaceAll]); wResposta := StringReplace(wResposta, '²', '2', [rfReplaceAll]); wResposta := StringReplace(wResposta, '³', '3', [rfReplaceAll]); wResposta := StringReplace(wResposta, '´', '4', [rfReplaceAll]); wResposta := StringReplace(wResposta, 'µ', '5', [rfReplaceAll]); wResposta := StringReplace(wResposta, '¶', '6', [rfReplaceAll]); wResposta := StringReplace(wResposta, '·', '7', [rfReplaceAll]); wResposta := StringReplace(wResposta, '¸', '8', [rfReplaceAll]); wResposta := StringReplace(wResposta, '¹', '9', [rfReplaceAll]); wResposta := StringReplace(wResposta, '[CR]', '', [rfReplaceAll]); // Modificado: Remover [CR] wResposta := StringReplace(wResposta, '[LF]', '', [rfReplaceAll]); // Modificado: Remover [LF] end Segue um trecho do log de pesagem: -------------------------------------------------------------------------------- ATIVAR - 04/04/22 14:22:34:841 - Modelo: Saturno - Porta: COM4 Device: BAUD=9600 DATA=8 PARITY=N STOP=1 HANDSHAKE= MAXBANDWIDTH=0 SENDBYTESCOUNT=0 SENDBYTESINTERVAL=0 -------------------------------------------------------------------------------- - 14:22:35:862 RX <- [CR]023060EL_ [LF][CR]023060EL_ [LF][CR]023060EL_ [LF][CR]023060EL_ [LF][CR]023060EL_ [LF] UltimoPesoLido: 0 - Resposta: [CR]023060EL_ [LF][CR]023060EL_ [LF][CR]023060EL_ [LF][CR]023060EL_ [LF][CR]023060EL_ [LF] O cliente ainda não informou o modelo em específico, mas assim que informar eu posto aqui. Gostaria de saber se alguém já passou por isso, se pode ser alguma particularidade do módulo que envia os pacotes de dados (alguma configuração como ele envia a resposta de peso), ou se realmente a alteração que eu fiz faz sentido e pode ser incluída no trunk do ACBr? Existe algum motivo do log gravar com esse [CR] e [LF] de forma literal? Seguem em anexo o código fonte modificado e o log de pesagem. Obrigado. ACBrBALSaturno.pas Log-Pesagem.log Teste-Balanca-Saturno-HerculesUtility.txt
  10. Imaginei mesmo, é uma alteração grande, teria que ser bem testada. Argumentei com o pessoal, que nem a biblioteca fiscal (ACBr) que usamos havia implementado as mudanças, sendo que o ACBr sempre sai na frente quanto às mudanças na legislação tributária. Mas ok, só precisava de uma confirmação a mais. Muito obrigado!
  11. Boa tarde, realmente, foi atualizada essa informação no ajuste. No PDF que recebi, não constava nada relacionado a 2023. E o atendente da Sefaz MT disse que até o momento não havia encontrado na legislação nada relativo a prorrogação, e que se deveria aguardar, mas daí fiquei em dúvida e decidi ver se mais alguém confirmava mais alguma coisa, pois ao que parece, as contabilidades da cidade estão dando a entender que vai entrar em vigor em 01/01/2022, mas acho que não estão sabendo dessa alteração de certo. Vou conversar com o pessoal do suporte aqui e repassar as informações. Obrigado!
  12. Boa tarde. Alguém sabe informar se sobre o ajuste SINIEF Nº 11/2019, referente ao novo “4 - Simples Nacional - Microempreendedor Individual - MEI” e a unificação da tabela CST, eliminando os códigos CSOSN, se ele foi prorrogado para o ano de 2023? Estamos acompanhando esse decreto (Decreto nº. 1047 de 2021), mas pelo visto em outras fontes, essa e outras alterações, como as de CFOP foram adiadas para Abril de 2023. Conforme um post que vi aqui no fórum ACBr, dá a entender que foi prorrogado. Pelo visto, também parece que o ACBr, pelo menos até a última revisão no svn, não tem nenhuma implementação a respeito ainda. Entrei em contato com a Sefaz do MT, mas disseram não encontrar nada a respeito dessa prorrogação, pediram para aguardar. Seguem as fontes que consultei: https://www.projetoacbr.com.br/forum/topic/65166-extinção-dos-csosn-sinief-1419/#comment-425422 https://www.confaz.fazenda.gov.br/legislacao/ajustes/2005/AJ007_05 https://www.contabilidadenatv.com.br/icms-prorrogacao-da-entrada-em-vigor-da-alteracao-das-cfop-e-cst/ https://www.valor.srv.br/artigo.php?id=85&titulo=codigo-de-regime-tributario-crt-e-codigo-de-situacao-da-operacao-no-simples-nacional-csosn Obrigado!
  13. Bom dia @EMBarbosa, entendido... Realmente, vi que na verdade o componente e os fontes ainda não estão compatibilizados com Delphi 7 e Lazarus. Agora estou trabalhando em outras questões, mas caso eu consiga posso adicionar as diretivas de compilação e ajustar a função de salvar os blocos para ficar compatível, e talvez até trocar na implementação para usar a "TACBrTXTClass" se for necessário, só não posso garantir isso agora, até porque a entrega do arquivo é em Abril ainda. Caso sobrar um tempo eu posso alterar e postar o as alterações novamente dentro de alguns dias. Obrigado.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.