Jump to content

Curso Dominando o ACBrMonitor
Novo Módulo Soluções de Varejo
Assine o SAC ACBr em qualquer plano e tenha acesso

Saiba Mais

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Saiba Mais

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Saiba mais

Leandro Araújo

Membros
  • Content Count

    131
  • Joined

  • Last visited

Community Reputation

16 Good

About Leandro Araújo

  • Rank
    Membro
  • Birthday 12/12/1990

Contact Methods

Profile Information

  • Sexo
    Masculino
  • Localização
    Mato Grosso - Brasil

Recent Profile Visitors

1,120 profile views
  1. 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.
  2. 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
  3. O "eles" a quem me refiro é a Receita Federal..
  4. 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?
  5. 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.
  6. 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.
  7. 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! UACBrLCDPR.pas
  8. 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. ACBrNFeDANFEFRDM.pas
  9. 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?
  10. Boa tarde. Qual banco de dados você usa e como está a precisão desses campos no banco?
  11. Boa tarde @Vicente Carletto Scalfoni, legal! Estava aguardando uma confirmação para enviar alterações. No caso deixei da seguinte forma, tendo que colocar na uses a "pcnConversao" claro, não sei se estaria misturando as coisas, mas só pra poder usar as funções "EnumeradoToStr/StrToEnumerado": // Valores Indicador Origem Processo const TACBrOrigemProcessoStr: array [0 .. 5] of string = ('0', '1', '2', '3', '9', ''); // ... function OrigemProcessoToStr(AValue: TACBrOrigemProcesso): string; begin Result := EmptyStr; Result := EnumeradoToStr(AValue, TACBrOrigemProcessoStr, [opSefaz, opJusticaFederal, opJusticaEstadual, opSecexRFB, opOutros, opNenhum]); end; function StrToOrigemProcesso(const AValue: string): TACBrOrigemProcesso; var WOk: Boolean; begin Result := opNenhum; Result := StrToEnumerado(WOk, AValue, TACBrOrigemProcessoStr, [opSefaz, opJusticaFederal, opJusticaEstadual, opSecexRFB, opOutros, opNenhum]); end; Mas no caso da sua correção, você manteve o padrão que jé tem nas funções da "ACBrEFDBlocos". Só uma pergunta, vi que anexou também o arquivo "ACBrEFDBloco_G_Class.pas", qual foi a correção feita nele? Obrigado!
  12. Bom dia. Tenho uma dúvida, com relação às funções "OrigemProcessoToStr" e "StrToOrigemProcesso" da unit "ACBrEFDBlocos". No Guia Prático da EFD, versão 2.0.21/2.0.22 o campo "07 - IND_PROC" do Registro "E116" recebe como valores válidos [0, 1, 2, 9], mas tive um problema ao validar o arquivo pelo PVA e percebi que nas funções são tratados apenas os valores [1, 3, 9], vide os tipos opJusticaFederal, opSecexRFB e opOutros. // Enumeração para string function OrigemProcessoToStr(AValue: TACBrOrigemProcesso): string; begin if (AValue = opJusticaFederal) then Result := '1' else if (AValue = opSecexRFB) then Result := '3' else if (AValue = opOutros) then Result := '9' else Result := ''; end; // string para enumeração function StrToOrigemProcesso(const AValue: string): TACBrOrigemProcesso; begin if AValue = '1' then Result := opJusticaFederal else if AValue = '3' then Result := opSecexRFB else if AValue = '9' then Result := opOutros else Result := opNenhum; end; /// Indicador da origem do processo TACBrOrigemProcesso = (opSefaz, // 0 - Sefaz opJusticaFederal, // 1 - Justiça Federal opJusticaEstadual, // 2 - Justiça Estadual opSecexRFB, // 3 - Secex/RFB opOutros, // 9 - Outros opNenhum // Preencher vazio ); Gostaria de saber se realmente são dessa forma as duas funções citadas ou se alguém teve também algum problema relacionado. De momento vou fazer a conversão do valor a parte para não modificar fontes do ACBr. Obrigado.
  13. Obrigado @Daniel S Ferreira, aqui deu certo também, no meu caso deixei assim: // Caso tenha que adicionar mais alguma UF: if (CUF in [51]) then // Quando MT adicionar caractere pipe entre o IdCSC e CSC. begin sCSC := cIdCSC + '|' + cCSC; end else begin sCSC := cIdCSC + cCSC; end; Sim @BigWings, não bate com as orientações do algoritmo indicado pelo manual, mas aqui no MT não está autorizando sem colocar o caractere pipe entre o IdCSC e o CSC. Seria algum erro do ambiente autorizador? Vou enviar um e-mail perguntando a eles se realmente no MT é assim, pra não correr o risco de ter que fazer alterações no componente novamente. Obrigado.
  14. Verifiquei o mesmo erro, quando em Debug, e mais especialmente quando no grupo dos impostos é informado o indicador de Simples Nacional, com outras tributações não aconteceu esse erro. Teria alguma coisa a ver com a estrutura do .xml ao componente ler o mesmo para gerar o DACTE? <ICMS> <ICMSSN> <indSN>1</indSN> </ICMSSN> </ICMS> Observei que sempre estoura no abaixo método da unit frxClass.pas: function TfrxCustomMemoView.CalcAndFormat(const Expr: WideString; Format: TfrxFormat): WideString; // ... begin // .... Result := FormatData(FValue, Format); // <- Para nessa linha (6812 na versão do FastReport que tenho) finally end; end; Ao que tudo indica alguma coisa com algum memo do .fr3, mas não consegui identificar.
×
×
  • Create New...