Jump to content

dia-do-acbr-online.png

Ganhe acesso a todas Palestras
Assinando o Suporte ACBr Comerecial

Saiba Mais


dia-do-acbr-online.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


botao.png

beneficios.png

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
  • Location
    Mato Grosso - Brasil

Recent Profile Visitors

1,197 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. Obr
  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
  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ã
  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, el
  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 dec
  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, [opSe
  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'
  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
  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(F
×
×
  • Create New...