Leandro Araújo
-
Total de ítens
145 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Leandro Araújo
-
-
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.
-
* 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!-
1
-
-
32 minutos atrás, Juliomar Marchetti disse:
tente usar um outro codepage pra ver se resolve
ela tem comandos ESC POS?
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.
-
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.
-
Em 06/05/2022 at 14:52, EMBarbosa disse:
Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão 25444.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.Mais uma vez obrigado.
Bom dia!
Testado e validado com sucesso aqui.
Obrigado @EMBarbosa
-
1 hora atrás, EMBarbosa disse:
Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão 25444.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.Mais uma vez obrigado.
Obrigado @EMBarbosa
Assim que possível vou atualizar pelo svn e realizo os testes, e informo novamente aqui. -
30 minutos atrás, Juliana Tamizou disse:
Obrigado pela contribuição, em breve será validada para possível inclusão ao svn
TK-2553
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!
-
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 endAcabei 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.
-
1
-
-
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-weightechWT27R
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/viewObrigado.
-
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] endSegue 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
-
16 horas atrás, Victor H. Gonzales - Panda disse:
um mudança pesada assim tem que sair schemas, e varias outras questões, e geralmente tem uma janela de pelo menos 180 dias .
Mas isso foi adiado, e já conversamos no papo pro a respeito disto.
Essas mudanças estão previstas para 2023, mas as vezes nem em 2023 será mudado, será adiado novamente, visto que 2022 é ano de eleição então tudo é complexo.
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!
-
20 minutos atrás, Victor H. Gonzales - Panda disse:
Boa tarde,
No próprio ajuste que você referenciou tem as informações que você pediu.
https://www.confaz.fazenda.gov.br/legislacao/ajustes/2019/ajuste-sinief-11-19
Está adiado para 2023 até o momento.
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!
-
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
Obrigado!
-
1 hora atrás, EMBarbosa disse:
Bom dia Leandro,
Infelizmente não podemos enviar a alteração da forma como está. Ela não é compatível nem com o Delphi 7, nem com o Lazarus.
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.
-
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.
-
2
-
-
21 minutos atrás, Leandro Araújo disse:
...
Até percebi que na versão 1.2 do layout eles mantiveram o código como 0011 e não 0012...
...
O "eles" a quem me refiro é a Receita Federal..
-
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?
-
2
-
-
9 horas atrás, Juliomar Marchetti disse:
Basta corrigir e anexar aqui que validaremos
Em 27/01/2020 at 10:37, izaquesouza disse:- Alterei a função 'formatDate' no arquivo LCDPRUtils.pas, para verificar se a data é nula e retornar ''. Este caso é quando a 'situação especial' é normal então o campo 'data da situação especial' deve ser nulo.
- Alterei a função 'formatNumeric' no arquivo LCDPRUtils.pas, adicionando mais um parâmetro chamado 'Size' opcional para adicionar um 'PadLeft'. Este caso é utilizado na % participação do imóvel, onde o manual e de tamanho (5,2), exemplo 10000 ou 09000 ou 00950.
- Criei a rotina de 'LimpaRegistros' para listar os blocos tipo 'List', sendo chamado antes de informar os blocos, para evitar que duplique toda vez que clicar em gerar.
UACBrLCDPR.pas 13 kB · 1 download LCDPRUtils.pas 3 kB · 1 download
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.
31 minutos atrás, Juliana Tamizou disse:Bom dia.
Indique por favor qual é o tópico criado.
Att.
O referido tópico é esse:
https://www.projetoacbr.com.br/forum/topic/56560-acbrlcdpr-salvando-arquivo-com-codificação-ansi/Obrigado.
-
1
-
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.
-
Boa tarde.
Realizando testes com a geração do arquivo do Livro Caixa do Produtor Rural (LCDPR), verifiquei que o componente não está gerando o arquivo com codificação UTF-8 conforme consta no manual do LCDPR no "Capítulo 2 – Dados Técnicos para Geração do Arquivo do LCDPR" página 4.
Como no momento o componente não está utilizando a classe "TACBrTXTClass" pra geração da estrutura, eu fiz uma pequena e rápida alteração na unit "\Fontes\ACBrTXT\ACBrLCDPR\UACBrLCDPR.pas" para que o arquivo sempre seja gerado com codificação UTF-8.
Obs.: Eu não vi a respeito, até porque o manual não fala nada sobre, mas caso seja necessário manter o BOM (Byte Order Marker) podem remover a linha adicionada no Create ou então passar o valor da propriedade WriteBOM para True.// Alteração no Create constructor TACBrLCDPR.Create(AOwner: TComponent); begin inherited; FBloco0000 := TRegistro0000.Create; FBloco0010 := TRegistro0010.Create; FBloco0030 := TRegistro0030.Create; FBloco0040 := TBlocos0040.Create; FBloco0050 := TBloco0050.Create; FBlocoQ := TBlocoQ.Create; FBloco9999 := TRegistro9999.Create; FDadosContador := TContador.Create; FConteudo := TStringList.Create; FConteudo.WriteBOM := False; // Salvar sem BOM FDelimitador := '|'; FArquivo := 'LCDPR'; end; //... // Alteração em SalvarBlocos procedure TACBrLCDPR.SalvarBlocos; begin FConteudo.SaveToFile(Path + Arquivo, TEncoding.UTF8); // Salvar com condificação UTF-8 end;Segue em anexo a unit "UACBrLCDPR.pas" com as alterações.
Se puderem verificar para ser adicionado no svn, ok?
Obrigado!
-
1
-
-
Boa tarde.
Gostaria de relatar um problema que ocorreu com nosso sistema emissor, com relação ao preview/impressão da Carta de Correção da NF-e.
O que acontece é que após exibir um DANFE e depois tentar exibir o preview de uma Carta de Correção ocorre um Access Violation, nesse caso testei apenas usando a engine FastReport.
Percebi que o erro ocorre nos métodos "PrepareReport" e "frxReportBeforePrint" da unit "Fontes\ACBrDFe\ACBrNFe\DANFE\NFe\Fast\ACBrNFeDANFEFRDM.pas".
Ao que parece o objeto NFe (FNFe) que é usado dentro deles está assigned mas suas propriedades estão nil, ele passa na verificação do Assigned(), mas ao acessar as propriedades elas estão nil.Se carregar uma NF-e no componente ACBrNFe e emitir um DANFE ele fica com referências apontadas internamente no DANFE associado ao ACBrNFe, então mesmo se der um ACBrNFe.NotasFiscais.Clear e carregar somente o XML do evento de CCe o erro ocorre.
O que eu fiz foi apenas passar nil para as variáveis FNFe e FEvento ao final de cada método "ImprimirDANFE", "ImprimirDANFEResumido", "ImprimirDANFEPDF", "ImprimirEVENTO", "ImprimirEVENTOPDF", "ImprimirINUTILIZACAO", "ImprimirINUTILIZACAOPDF", para assim não apontar para uma referência inválida e a verificação funcionar corretamente em "PrepareReport" e "frxReportBeforePrint".
// Está em "ImprimirDANFE", "ImprimirDANFEResumido", "ImprimirDANFEPDF", "ImprimirEVENTO", "ImprimirEVENTOPDF", "ImprimirINUTILIZACAO", "ImprimirINUTILIZACAOPDF": { DONE -oLeandro : (03/09/2019) - Alteração para não causar AccessViolation após: 1 - Imprimir um DANFE; 2 - Imprimir um Evento (Carta de Correção); AccessViolation ocorre nos métodos: * PrepareReport * frxReportBeforePrint Provável motivo: Objeto NFe (FNFe) está assigned mas suas propriedades estão nil. } FNFe := nil; FEvento := nil;Segue o arquivo ACBrNFeDANFEFRDM.pas em anexo, as alterações estão marcadas com um "DONE -oLeandro :" , se a alteração proceder e for útil, peço aos administradores que adicionem a alteração no svn.
Muito obrigado.
-
1
-
-
17 horas atrás, rodrigoogioni disse:
Boa tarde Leandro,
Firebird 3.0 e os campos monetarios utilizo Double Precision
Grato
Entendi.
No caso, aqui com MySQL usamos o tipo Decimal com escala/precisão de 25,10, ficando: Decimal(25,10), em alguns outros casos para quantidades e outros valores usamos o Double(25,10).Deixamos o banco gravar um bom número de decimais, mesmo que não use, e tratamos o arredondamento nos cálculos do lado da aplicação usando o método SimpleRoundTo, não tivemos mais problemas com arredondamentos.
As máscaras dos campos também ficam dinâmicas, configuradas na inicialização do sistema conforme uma configuração pré-definida.
Não seria melhor você aumentar a quantidade de casas decimais para o banco gravar e tratar esses arredondamentos no código?
Outra coisa, tem algum outro tipo pra monetário no FireBird? -
Boa tarde.
Qual banco de dados você usa e como está a precisão desses campos no banco? -
3 minutos atrás, Vicente Carletto Scalfoni disse:
No "ACBrEFDBloco_G_Class.pas" alterei o "G110" para usar a função "MovimentoBensToStr" que incluir no "ACBrEFDBlocos".
Certo, entendi.
Não vou anexar nada então, no caso ficam as alterações que você enviou mesmo, que engloba tudo.Obrigado.
Impressora Diebold IM453HU-002 não imprime QRCode (Impressão em papel térmico) pelo ACBrPOSPrinter.
em ACBrSerial
Postado
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!