Ir para conteúdo
  • Cadastre-se

Leandro Araújo

Membros
  • Total de ítens

    155
  • Registro em

  • Última visita

Tudo que Leandro Araújo postou

  1. 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
  2. O "eles" a quem me refiro é a Receita Federal..
  3. 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?
  4. 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.
  5. 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.
  6. 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
  7. 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
  8. 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?
  9. Boa tarde. Qual banco de dados você usa e como está a precisão desses campos no banco?
  10. Certo, entendi. Não vou anexar nada então, no caso ficam as alterações que você enviou mesmo, que engloba tudo. Obrigado.
  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.
  15. Fiz isso também, deu certo. Obrigado.
  16. @CleitonMaciel, Exatamente, é só seguir os passos e dá certo... Algum problema com a tela de exportação do próprio Fast Report, removendo e adicionando novamente o componente resolve. Muito obrigado.
  17. Boa tarde. Me corrijam se eu estiver errado, mas com relação a esse erro o que acontece é que para quem tinha uma revisão anterior do ACBr, a propriedade ImprimirUnQtVlComercial que está na unit ACBrNFeDANFEFR dos fontes do ACBr era do tipo Boolean, porém o tipo dessa propriedade foi atualizado para TImprimirUnidQtdeValor, no código fonte está atualizado, mas para o componente em design-time para se trabalhar no IDE (o arquivo .bpl) ainda continua como tipo Boolean, ao recompilar os pacotes pelo instalador do ACBr as .bpl's são geradas novamente, com o tipo correspondente nos fontes. // Unit ...\ACBr\Fontes\ACBrDFe\ACBrNFe\DANFE\NFe\Fast\ACBrNFeDANFEFR.pas // Linha 120: // (Aqui antes era Boolean, necessário recompilar para gerar o tipo corrento na .bpl para usar em tempo de design no projeto, // caso contrário é realizada a tentativa de injetar um valor Boolean dentro de uma propriedade do tipo Enum, // por isso o erro "EReadError, invalid property value"): property ImprimirUnQtVlComercial: TImprimirUnidQtdeValor read FImprimirUnQtVlComercial write FImprimirUnQtVlComercial; Eu também estava com esse problema, recompilei e resolvi. Dica: Para evitar possíveis erros de compilação, remova da library do seu Delphi os path's referentes a componentes de terceiros, deixando somente suítes de relatórios, JEDI e o essencial, depois disso volte como estava, com os caminhos do ACBr junto, obviamente. Boa sorte e bom trabalho a todos.
  18. Bom dia. Era isso mesmo que queria saber. Então aqui no meu caso só irei consultar o recibo em um caso de falha na comunicação, etc, já que o componente realiza essa consulta imediata no envio. Obrigado.
  19. Observei o comportamento do componente, e ele faz a consulta do recibo automaticamente: // Se utilizar a chamada: ...Enviar(FLote, FImprimir); Pois na unit 'ACBrCTeWebServices' linhas 2970-2982, internamente ele faz a consulta imediata do recibo. // 'ACBrCTeWebServices' linhas 2970-2982: function TWebServices.Envia(ALote: String): Boolean; begin FEnviar.Lote := ALote; if not Enviar.Executar then Enviar.GerarException( Enviar.Msg ); FRetorno.Recibo := FEnviar.Recibo; if not FRetorno.Executar then FRetorno.GerarException( FRetorno.Msg ); Result := True; end; Sendo assim, não preciso realizar a consulta manualmente do recibo em uma primeira tentativa de envio, certo? Obrigado.
  20. Sobre modal Rodoviário Outros Serviços era essa a dúvida que eu precisava tirar, já que nele possui o TAF. Muito obrigado @Italo Jurisato Junior, já li bastante o manual, inclusive comparando com o da versão 2.00, vou observar com mais atenção, mas agora ficou mais esclarecido sobre esse ponto. Obrigado.
  21. É pessoal, acho que não tem o que discutir mesmo, é o que o manual e o o pacote de liberação PL_CTe_300 indicam. E também aqui nessa página Análise Técnica das Diferenças no Manual do CTe v3.00 fala que todo o grupo de Veículos (0-4) foi excluído, portanto agora podendo ser informado 1 no grupo rodoOS. Independentemente, muito obrigado a todos, alguém quiser dizer alguma coisa sobre o assunto é bem-vindo.
  22. Na codificação, seria esse caso: // V2.00 ...Conhecimentos.Add.CTe.infCTeNorm.rodo.veic.Add... // Coleção // V3.00 ...Conhecimentos.Add.CTe.infCTeNorm.rodoOS.veic... // Único objeto É isso mesmo? Obrigado.
  23. Bom dia. Estamos desenvolvendo uma aplicação emissora de CT-e aqui na empresa, utilizando o manual da versão 3.00. Observei que na versão 2.00 era possível informar até 4 veículos, nos dados do Modal Rodoviário, porém agora na versão 3.00, analisando os schemas e o próprio manual é possível informar apenas 1 veículo, é isso mesmo? E lembrando também que agora os dados do veículo foram passados do grupo (Rodo) para o grupo (RodoOS). Pergunto, por que gostaria de saber, se caso precisar informar mais de 1 veículo, que nem na versão 2.00? Modal Rodoviário 2.00 - Diagrama Manual: Modal Rodoviário OS 3.00 - Veículos: Modal Rodoviário OS 3.00 - Diagrama Manual: Modal Rodoviário OS 3.00 - Definição schema: Não continuei a implementação pois preciso tirar essa dúvida, já que para construir a interface gráfica para alimentar esses dados, estou dependendo dessa informação. Obrigado.
  24. Também estava a procura dessa informação. Obrigado.
  25. Olá @Mailson Popin, bom dia. O referido post é esse: Atualmente estamos utilizando Capicom com certificados A3 em Windows 7/8/10, fora isso, nossos clientes que utilizam A1 estamos utilizando OpenSSL mesmo, não testamos mais Capicom nos Windows Server 2003/2008. Espero que o post possa te ajudar de alguma maneira.
×
×
  • 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.

The popup will be closed in 9 segundos...