Jump to content

Leandro Araújo

Membros
  • Posts

    140
  • Joined

  • Last visited

Recent Profile Visitors

1,395 profile views

Leandro Araújo's Achievements

Collaborator

Collaborator (7/14)

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

Recent Badges

17

Reputation

2

Community Answers

  1. Obrigado @EMBarbosa Assim que possível vou atualizar pelo svn e realizo os testes, e informo novamente aqui.
  2. 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!
  3. 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
  4. 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.
  5. 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
  6. 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!
  7. 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!
  8. 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!
  9. 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.
  10. Certo, tudo bem... Segue em anexo a unit "LCDPRBlocos.pas" com a alteração na função CodVerToStr para gerar o campo "3 - Código da versão do leiaute " do bloco 0000 com o valor 0013. Peço aos administradores quando possível validarem e adicionar ao svn. Obrigado. LCDPRBlocos.pas
  11. O "eles" a quem me refiro é a Receita Federal..
  12. Boa tarde. Verifiquei também, realmente está faltando uma opção no enumerado TCodVer. Deveria haver um "Versao013" para tratar a nova versão do layout na função CodVerToStr. Até percebi que na versão 1.2 do layout eles mantiveram o código como 0011 e não 0012... Mas enfim, é isso mesmo, caso queira eu posso modificar e anexar a unit "LCDPRBlocos.pas" alterada, ou você já fez alguma correção?
  13. Na verdade já foi corrigido pelo @izaquesouza como descrito no tópico, com os arquivos anexados por ele. Só não vi as alterações dele no svn até a revisão (19276) de ontem (02/03/2020), quando fui mandar minha contribuição. Acho que ainda não foi feito o merge, isso? Não queria misturar o assunto do tópico com a alteração que fiz, por isso só estou avisando que não foi feito o merge. As alterações não encontradas no svn são a 1 e 2 citadas, a alteração 3 (com relação a limpeza dos registros) feita por ele também não se encontra, mas parece que outro membro já fez uma alteração parecida, que já se encontra no svn: https://www.projetoacbr.com.br/forum/topic/56293-o-lcdpr-não-está-limpando-as-informações-dos-campos-ao-gerar-pela-segunda-vez/ Com relação a minha alteração, que não envolve o mesmo assunto é o link a seguir: https://www.projetoacbr.com.br/forum/topic/56560-acbrlcdpr-salvando-arquivo-com-codificação-ansi/ Obrigado. O referido tópico é esse: https://www.projetoacbr.com.br/forum/topic/56560-acbrlcdpr-salvando-arquivo-com-codificação-ansi/ Obrigado.
  14. Boa tarde, gostaria de saber se a alteração com relação a "Data da Situação especial nula" que o colega acima contribuiu já foi para o svn? Fiz a atualização hoje, na revisão 19276 e ao verificar os logs vi que essa alteração ainda não consta. Estou perguntando porque hoje descobri um pequeno problema e criei um post com uma pequena alteração, também no arquivo "UACBrLCDPR.pas". Obrigado.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.